* Hilscher NetX mach-netx refactorings @ 2019-01-12 8:35 Linus Walleij 2019-01-12 12:03 ` Arnd Bergmann 2019-01-14 10:35 ` Sascha Hauer 0 siblings, 2 replies; 11+ messages in thread From: Linus Walleij @ 2019-01-12 8:35 UTC (permalink / raw) To: Robert Schwebel, Pengutronix Kernel Team Cc: Olof Johansson, Arnd Bergmann, Linux ARM Hi Sascha, Robert, I am looking at refactoring mach-netx to use the new PL11x DRM driver for the graphics. I need to make sure that patches get tested on the hardware and just want to ascertain that there is an active maintainer that will be able to test patches I make for this and work on getting it migrated to DRM before I start spending time on it. Are you/pengutronix still actively maintaining this machine and testing new kernels on netx? I guess the second question is whether you have plans to migrate it to device tree and multiplatform, but I'm mainly thinking about my own little patches now. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hilscher NetX mach-netx refactorings 2019-01-12 8:35 Hilscher NetX mach-netx refactorings Linus Walleij @ 2019-01-12 12:03 ` Arnd Bergmann 2019-01-13 12:14 ` Linus Walleij 2019-01-14 10:35 ` Sascha Hauer 1 sibling, 1 reply; 11+ messages in thread From: Arnd Bergmann @ 2019-01-12 12:03 UTC (permalink / raw) To: Linus Walleij Cc: Olof Johansson, Robert Schwebel, Linux ARM, Pengutronix Kernel Team On Sat, Jan 12, 2019 at 9:35 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > Hi Sascha, Robert, > > I am looking at refactoring mach-netx to use the new PL11x > DRM driver for the graphics. > > I need to make sure that patches get tested on the hardware > and just want to ascertain that there is an active maintainer that > will be able to test patches I make for this and work on getting > it migrated to DRM before I start spending time on it. > > Are you/pengutronix still actively maintaining this machine and > testing new kernels on netx? > > I guess the second question is whether you have plans to migrate > it to device tree and multiplatform, but I'm mainly thinking about > my own little patches now. On a related note, there does appear to be active work on newer netx machines that were never upstreamed, see https://github.com/Hilscher/netx4000-linux/commits/v4.9-netx4000-stable I wonder if anyone has contacts into the company so we can work together with them to include them into mainline Linux. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hilscher NetX mach-netx refactorings 2019-01-12 12:03 ` Arnd Bergmann @ 2019-01-13 12:14 ` Linus Walleij 2019-01-13 15:50 ` Ladislav Michl 2019-01-14 11:26 ` Michael Trensch 0 siblings, 2 replies; 11+ messages in thread From: Linus Walleij @ 2019-01-13 12:14 UTC (permalink / raw) To: Arnd Bergmann, Ladislav Michl, github Cc: Olof Johansson, Robert Schwebel, Linux ARM, Pengutronix Kernel Team On Sat, Jan 12, 2019 at 1:03 PM Arnd Bergmann <arnd@arndb.de> wrote: > On Sat, Jan 12, 2019 at 9:35 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > > > Hi Sascha, Robert, > > > > I am looking at refactoring mach-netx to use the new PL11x > > DRM driver for the graphics. > > > > I need to make sure that patches get tested on the hardware > > and just want to ascertain that there is an active maintainer that > > will be able to test patches I make for this and work on getting > > it migrated to DRM before I start spending time on it. > > > > Are you/pengutronix still actively maintaining this machine and > > testing new kernels on netx? > > > > I guess the second question is whether you have plans to migrate > > it to device tree and multiplatform, but I'm mainly thinking about > > my own little patches now. > > > On a related note, there does appear to be active work on > newer netx machines that were never upstreamed, see > https://github.com/Hilscher/netx4000-linux/commits/v4.9-netx4000-stable That RS485 addition to PL011 using GPIOs is a bit hacky but looks like very useful for industrial applications. Ladislav, have you been in contact with Hilscher? > I wonder if anyone has contacts into the company so we can > work together with them to include them into mainline Linux. They have a mail address github@hilscher.com, let's knock on the door and see if somebody answers it :D I'd personally be able to take a stab at converting this machine to device tree and multiplatform if I only had access to the hardware, as it seems to be in the same class as EP93xx and MOXA ART: deployed in industrial systems as we speak. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hilscher NetX mach-netx refactorings 2019-01-13 12:14 ` Linus Walleij @ 2019-01-13 15:50 ` Ladislav Michl 2019-01-13 22:39 ` Linus Walleij 2019-01-14 11:26 ` Michael Trensch 1 sibling, 1 reply; 11+ messages in thread From: Ladislav Michl @ 2019-01-13 15:50 UTC (permalink / raw) To: Linus Walleij Cc: Arnd Bergmann, Robert Schwebel, Pengutronix Kernel Team, Olof Johansson, github, Linux ARM Hi Linus, On Sun, Jan 13, 2019 at 01:14:36PM +0100, Linus Walleij wrote: > On Sat, Jan 12, 2019 at 1:03 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Sat, Jan 12, 2019 at 9:35 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > > > > > Hi Sascha, Robert, > > > > > > I am looking at refactoring mach-netx to use the new PL11x > > > DRM driver for the graphics. > > > > > > I need to make sure that patches get tested on the hardware > > > and just want to ascertain that there is an active maintainer that > > > will be able to test patches I make for this and work on getting > > > it migrated to DRM before I start spending time on it. > > > > > > Are you/pengutronix still actively maintaining this machine and > > > testing new kernels on netx? > > > > > > I guess the second question is whether you have plans to migrate > > > it to device tree and multiplatform, but I'm mainly thinking about > > > my own little patches now. > > > > > > On a related note, there does appear to be active work on > > newer netx machines that were never upstreamed, see > > https://github.com/Hilscher/netx4000-linux/commits/v4.9-netx4000-stable > > That RS485 addition to PL011 using GPIOs is a bit hacky but > looks like very useful for industrial applications. > Ladislav, have you been in contact with Hilscher? I guess I appeared on Cc list because of commit 797537a45450 ("amba-pl011: Add RS485 support (ioctl and devicetree)") from above github repo which is based on my hack originaly done for rPi3 as I got tired of all those experts implementing 'drive enable' in userspace. That's broken by design and works only by accident. But as I'm also considering every single device running from SD card broken by design - it was perfect match ;-) But seriously, it is indeed needed for industrial applications and should be done a bit better - I mean regarding those delays in interrupt context. > > I wonder if anyone has contacts into the company so we can > > work together with them to include them into mainline Linux. I do not own this machine nor I was in contact with Hilscher, but I can help with mainlining PL011's RS485 support. It is only matter of time until someone brings some "product" based on RPi claiming "it almost works, it just needs a bit of fixing" ;-) So having that in mainline would save some future effort. > They have a mail address github@hilscher.com, let's knock > on the door and see if somebody answers it :D > > I'd personally be able to take a stab at converting this machine > to device tree and multiplatform if I only had access to the > hardware, as it seems to be in the same class as EP93xx > and MOXA ART: deployed in industrial systems as we speak. > > Yours, > Linus Walleij Best regards, ladis _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hilscher NetX mach-netx refactorings 2019-01-13 15:50 ` Ladislav Michl @ 2019-01-13 22:39 ` Linus Walleij 0 siblings, 0 replies; 11+ messages in thread From: Linus Walleij @ 2019-01-13 22:39 UTC (permalink / raw) To: Ladislav Michl Cc: linux-serial, Arnd Bergmann, Robert Schwebel, Pengutronix Kernel Team, Olof Johansson, github, Linux ARM On Sun, Jan 13, 2019 at 4:50 PM Ladislav Michl <ladis@linux-mips.org> wrote: > On Sun, Jan 13, 2019 at 01:14:36PM +0100, Linus Walleij wrote: > > > On a related note, there does appear to be active work on > > > newer netx machines that were never upstreamed, see > > > https://github.com/Hilscher/netx4000-linux/commits/v4.9-netx4000-stable > > > > That RS485 addition to PL011 using GPIOs is a bit hacky but > > looks like very useful for industrial applications. > > Ladislav, have you been in contact with Hilscher? > > I guess I appeared on Cc list because of commit 797537a45450 ("amba-pl011: > Add RS485 support (ioctl and devicetree)") from above github repo which > is based on my hack originaly done for rPi3 as I got tired of all those > experts implementing 'drive enable' in userspace. That's broken by design > and works only by accident. I suppose it is one of those GPIO hacks in userspace. Yeah that makes the GPIO maintainer very unhappy I can tell you that :/ > But as I'm also considering every single > device running from SD card broken by design - it was perfect match ;-) Ha ha ;) > But seriously, it is indeed needed for industrial applications and > should be done a bit better - I mean regarding those delays in interrupt > context. I suppose this thing is a bit of an oddity since the PL011 does have an RTS signal, but in this case (for reasons such as hardware doesn't do the right thing, or the hardware engineer didn't care do make it possible to get the RTS line out of the chip, or the board engineer didn't think of it) a GPIO is used for RTS instead. So what the patch does is add that as an option. There are DT bindings for RTS (etc): Documentation/devicetree/bindings/serial/serial.txt I think that GPIO support code could be implemented using the library in: drivers/tty/serial/serial_mctrl_gpio.c This makes it possible to handle any extra "modem control" pins using GPIO. I think it is fine to just look for RTS if that is all that's needed. Possibly those extra delay settings could be added in mctrl and added as generic DT bindings as well. (I'm not smart enough to tell if that is possible.) Sorry for the sidetrack. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Hilscher NetX mach-netx refactorings 2019-01-13 12:14 ` Linus Walleij 2019-01-13 15:50 ` Ladislav Michl @ 2019-01-14 11:26 ` Michael Trensch 2019-01-14 14:22 ` Linus Walleij 1 sibling, 1 reply; 11+ messages in thread From: Michael Trensch @ 2019-01-14 11:26 UTC (permalink / raw) To: Linus Walleij, Arnd Bergmann, Ladislav Michl Cc: Olof Johansson, Robert Schwebel, Linux ARM, Pengutronix Kernel Team Hi all, I am working for Hilscher and responsible with my group for linux running on our new SoCs (netX4000 currently), due to a corporate guideline all public mail addresses for github projects is set to github@hilscher.com to distribute them to the proper department. Maybe I can shed some light into this matter. On 13.01.2019 13:14, Linus Walleij wrote: > On Sat, Jan 12, 2019 at 1:03 PM Arnd Bergmann <arnd@arndb.de> wrote: >> On Sat, Jan 12, 2019 at 9:35 AM Linus Walleij <linus.walleij@linaro.org> wrote: >> >> On a related note, there does appear to be active work on >> newer netx machines that were never upstreamed, see >> https://github.com/Hilscher/netx4000-linux/commits/v4.9-netx4000-stable This work is not combatible with the mainlined netx platform, which is netX100/500, but for a new netX SoC, called netX 4000. Currently we have not had any plans or schedule to get it mainline yet, as we needed to get it finished first. That does not mean we don't want it to become mainline. This surely depends on the number of requests that arise for this specific SoC. More information on the netX 4000 SoC itself can be found here: https://www.hilscher.com/products/product-groups/network-controller/asics/netx-4000/ When trying to bring it mainline, I see, at the current point, some more work arising, as we needed to patch some mainline sources due to some chip specialties like: * nbpfaxi: static-wired-dma-channels -> https://github.com/Hilscher/netx4000-linux/commit/a3fb58c531caf0da1d8eba90171bc4a8ce2d1da3. I don't know if such a patch is legit or if it should be more universal * nand specialities from a pl353 driver starting at -> https://github.com/Hilscher/netx4000-linux/commit/f7da2b259b71439a0c6662af8697292fe2c3afda * Device-tree files are currently hosted in yocto recipes (https://github.com/Hilscher/meta-hilscher-netx4000/tree/master/files/dts) to prevent maintenance / syncing issues on our side * CAN driver which is taken / ported from rza1_can -> https://github.com/Hilscher/netx4000-linux/commit/46ca8736f44bf8000ac41717efb77f188db1f68e https://github.com/Hilscher/netx4000-linux/commit/f08e62e0c114b5e8037e44979317f6e777671140 * Framebuffer display driver -> https://github.com/Hilscher/netx4000-linux/commit/ceee73345214504bf8e7c2a9124519e55e2b2b79 > That RS485 addition to PL011 using GPIOs is a bit hacky but > looks like very useful for industrial applications. > Ladislav, have you been in contact with Hilscher? > >> I wonder if anyone has contacts into the company so we can >> work together with them to include them into mainline Linux. > > They have a mail address github@hilscher.com, let's knock > on the door and see if somebody answers it :D > It indeed is hacky, and derived from a patch found on the mailing list / patchwork to get it quickly working for one of our customers, who is not using any delays at all. As already stated somewhere, the problem indeed is the missing modem control signals, due to pin count limitations and lack of more pin function multiplexers, on some uarts on this chip. That's why they need to be emulated via GPIOs. More or less, when it comes to delays the PL011s modem control line would need to be set manually as well. > I'd personally be able to take a stab at converting this machine > to device tree and multiplatform if I only had access to the > hardware, as it seems to be in the same class as EP93xx > and MOXA ART: deployed in industrial systems as we speak. > The netX4000 platform is only built using a device tree. The device tree files were sometime ago moved out of the kernel into our yocto layer to reduce maintenance and have a single location. I know this conflicts with mainlining. I don't know what needs additionally to be done for working multiplatform support. Mit freundlichen Grüßen / Best regards Michael Trensch -- Michael Trensch | netX System Phone: +49 (0) 6190 9907-0 | Fax: +49 (0) 6190 9907-50 Hilscher Gesellschaft für Systemautomation mbH | Rheinstrasse 15 | 65795 Hattersheim | Germany | www.hilscher.com<http://www.hilscher.com> Sitz der Gesellschaft / place of business: Hattersheim | Geschäftsführer / managing director: Dipl.-Ing. Hans-Jürgen Hilscher Handelsregister / commercial register: Frankfurt B 26873 | Ust. Idnr. / VAT No.: DE113852715 Registergericht / register court: Amtsgericht Frankfurt/Main Important Information: This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails. Wichtiger Hinweis: Diese E-Mail einschließlich ihrer Anhänge enthält vertrauliche und rechtlich geschützte Informationen, die nur für den Adressaten bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und löschen Sie diese Nachricht und ihre Anhänge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Veränderung der E-Mail ist untersagt. Der Absender haftet nicht für Inhalte von veränderten E-Mails. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Hilscher NetX mach-netx refactorings 2019-01-14 11:26 ` Michael Trensch @ 2019-01-14 14:22 ` Linus Walleij 2019-01-15 7:05 ` Michael Trensch 2019-01-15 10:14 ` Arnd Bergmann 0 siblings, 2 replies; 11+ messages in thread From: Linus Walleij @ 2019-01-14 14:22 UTC (permalink / raw) To: Michael Trensch Cc: Ladislav Michl, Arnd Bergmann, Robert Schwebel, nagasureshkumarrelli, Pengutronix Kernel Team, Olof Johansson, Linux ARM Hi Michael! Thanks for interacting with the community and helping us out! On Mon, Jan 14, 2019 at 12:26 PM Michael Trensch <MTrensch@hilscher.com> wrote: > I am working for Hilscher and responsible with my group for linux > running on our new SoCs (netX4000 currently), due to a corporate > guideline all public mail addresses for github projects is set to > github@hilscher.com to distribute them to the proper department. Fair enough, this clearly works. > >> On a related note, there does appear to be active work on > >> newer netx machines that were never upstreamed, see > >> https://github.com/Hilscher/netx4000-linux/commits/v4.9-netx4000-stable > > This work is not combatible with the mainlined netx platform, which is > netX100/500, but for a new netX SoC, called netX 4000. So a pressing question is whether it is OK with Hilscher that we decomission/delete the current support code for NetX nxdkn, nxdb500 and nxeb500hmi? Or are these products that still see active deployment (new designs) and maintenance in the long term (5-10 years from now)? > Currently we have > not had any plans or schedule to get it mainline yet, as we needed to > get it finished first. That does not mean we don't want it to become > mainline. This surely depends on the number of requests that arise for > this specific SoC. OK! But when you have time and resources, please consider to work with the kernel community to get the board support upstream. > More information on the netX 4000 SoC itself can be found here: > https://www.hilscher.com/products/product-groups/network-controller/asics/netx-4000/ This is an interesting SoC, primarily for the use of an A7 coprocessor for an RTOS. We have seen a number of devices of this type. You might be interested in looking into OpenAMP for the communcation with the RTOS core. The industry has identified fragmentation in the shared-memory (and other) AMP solutions and try to standardize that communication around RPMSG. This is good because the Linux side of things is very well tested and stable, and we don't get too many deviant AMP mechanisms to deal with in the kernel. https://www.multicore-association.org/workgroup/oamp.php > When trying to bring it mainline, I see, at the current point, some more > work arising, as we needed to patch some mainline sources due to some > chip specialties like: Trying to add my €0.05 here... > * nbpfaxi: static-wired-dma-channels -> > https://github.com/Hilscher/netx4000-linux/commit/a3fb58c531caf0da1d8eba90171bc4a8ce2d1da3. > I don't know if such a patch is legit or if it should be more universal #ifdef is generally frowned upon and does not work with the multiplatform paradigm (one kernel image for all, many device trees). But certainly the DMA subsystem maintainers will help out finding the right solution if you talk to them (they have a separate mailing list and everything). > * nand specialities from a pl353 driver starting at -> > https://github.com/Hilscher/netx4000-linux/commit/f7da2b259b71439a0c6662af8697292fe2c3afda I was involved in reviewing a PL353 driver that was sent by Naga Sureshkumar Relli from Xlilinx so I guess that is what you are using? I have no idea on whether this is the right approach for ioremap() or if that is even what you want to do for a NAND driver. I think Naga is still working on this rawnand driver, certainly you can be added to the reviewers of the driver as we work with it in the community. > * Device-tree files are currently hosted in yocto recipes > (https://github.com/Hilscher/meta-hilscher-netx4000/tree/master/files/dts) > to prevent maintenance / syncing issues on our side These can all be merged into the kernel proper when the platform lands upstream. I can see that your clock implementation will probably need some changes using cells for clock type rather than compatible, otherwise it looks pretty standard. > * CAN driver which is taken / ported from rza1_can -> > https://github.com/Hilscher/netx4000-linux/commit/46ca8736f44bf8000ac41717efb77f188db1f68e > https://github.com/Hilscher/netx4000-linux/commit/f08e62e0c114b5e8037e44979317f6e777671140 I suppose it is so similar that we can simply augment what we have in the upstream kernel to also support your variant. > * Framebuffer display driver -> > https://github.com/Hilscher/netx4000-linux/commit/ceee73345214504bf8e7c2a9124519e55e2b2b79 I would reimplement this using DRM. Simple framebuffers are quite easy to support with DRM nowadays, see for example: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/tve200 > As already stated somewhere, the problem indeed is the missing modem > control signals, due to pin count limitations and lack of more pin > function multiplexers, on some uarts on this chip. That's why they need > to be emulated via GPIOs. More or less, when it comes to delays the > PL011s modem control line would need to be set manually as well. We can certainly work out an "approved quirk" in the upstream kernel to handle this given the very straight-forward usecase. It requires some time and tinkering like everything else. > The netX4000 platform is only built using a device tree. The device tree > files were sometime ago moved out of the kernel into our yocto layer to > reduce maintenance and have a single location. I know this conflicts > with mainlining. No big deal where you keep the files as long as they are merged when we implement the platform in the upstream kernel. > I don't know what needs additionally to be done for working > multiplatform support. I would simply look at one of the similar platform in the upstream kernel, starting with v5.0-rc1 and following the pattern set in presentations like these: https://elinux.org/images/2/2a/Schulz-how-to-support-new-board-u-boot-linux.pdf https://elinux.org/images/1/18/ARM64_SoC_Linux_Support_Check-List.pdf https://elinux.org/images/2/26/Getting-Your-Patches-in-Mainline-Linux-What-Not-To-Do-and-a-Few-Things-You-Could-Try-Instead-Marc-Zyngier-ARM.pdf Gregory's presentation (second) is especially helpful for a new Linux subarchitecture specifically. Multiplatform is generally just making sure that all system-specific code will only run for that specific device tree that represents your specific system. The multiplatform in this case is ARCH_MULTI_V7. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hilscher NetX mach-netx refactorings 2019-01-14 14:22 ` Linus Walleij @ 2019-01-15 7:05 ` Michael Trensch 2019-01-15 10:11 ` Arnd Bergmann 2019-01-15 10:14 ` Arnd Bergmann 1 sibling, 1 reply; 11+ messages in thread From: Michael Trensch @ 2019-01-15 7:05 UTC (permalink / raw) To: Linus Walleij Cc: Ladislav Michl, Arnd Bergmann, Robert Schwebel, nagasureshkumarrelli, Pengutronix Kernel Team, Olof Johansson, Linux ARM Hi Linus, On 14.01.2019 15:22, Linus Walleij wrote: > So a pressing question is whether it is OK with Hilscher that we > decomission/delete the current support code for NetX > nxdkn, nxdb500 and nxeb500hmi? Or are these products that > still see active deployment (new designs) and maintenance > in the long term (5-10 years from now)? > It's ok from Hilscher side. I've talked to our CEO and he is fine with dropping it. Those boards are not produced anymore and our new Asics (e.g. netX4000 and upcoming) will replace netX100/500 in the long term. Our Asics usually have a guaranteed lifecycle of 10 years and netX100 has been around since 2006, if I remember correctly, so we don't expect many new linux projects arising, with the need for the newest kernel. Old kernel version will still be working though. > OK! But when you have time and resources, please consider to > work with the kernel community to get the board support upstream. > We want to work with the community now and in the future, but for netX4000 we first needed to get this SoC working. It took many development cycles to get all implementation working and now it seems to have settled so we can think about step two. netX4000 Final (with all required changes) was released end of last year. Main problem would have been the continuous change of the Asic during development and more or less constant changes to kernel sources. I think this would have caused some laughing on the mailing list if we submit a patch one day and do it the complete other way round with the next (possibly non-public) stepping of the Asic. But probably that's just my personal feeling. Thanks for all your valuable input. I will take a look an see what I can do about it. Mit freundlichen Grüßen / Best regards Michael Trensch -- Michael Trensch | netX System Phone: +49 (0) 6190 9907-0 | Fax: +49 (0) 6190 9907-50 Hilscher Gesellschaft für Systemautomation mbH | Rheinstrasse 15 | 65795 Hattersheim | Germany | www.hilscher.com<http://www.hilscher.com> Sitz der Gesellschaft / place of business: Hattersheim | Geschäftsführer / managing director: Dipl.-Ing. Hans-Jürgen Hilscher Handelsregister / commercial register: Frankfurt B 26873 | Ust. Idnr. / VAT No.: DE113852715 Registergericht / register court: Amtsgericht Frankfurt/Main Important Information: This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails. Wichtiger Hinweis: Diese E-Mail einschließlich ihrer Anhänge enthält vertrauliche und rechtlich geschützte Informationen, die nur für den Adressaten bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und löschen Sie diese Nachricht und ihre Anhänge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Veränderung der E-Mail ist untersagt. Der Absender haftet nicht für Inhalte von veränderten E-Mails. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hilscher NetX mach-netx refactorings 2019-01-15 7:05 ` Michael Trensch @ 2019-01-15 10:11 ` Arnd Bergmann 0 siblings, 0 replies; 11+ messages in thread From: Arnd Bergmann @ 2019-01-15 10:11 UTC (permalink / raw) To: Michael Trensch Cc: Ladislav Michl, Linus Walleij, nagasureshkumarrelli, Pengutronix Kernel Team, Olof Johansson, Robert Schwebel, Linux ARM On Tue, Jan 15, 2019 at 8:05 AM Michael Trensch <MTrensch@hilscher.com> wrote: > On 14.01.2019 15:22, Linus Walleij wrote: > > So a pressing question is whether it is OK with Hilscher that we > > decomission/delete the current support code for NetX > > nxdkn, nxdb500 and nxeb500hmi? Or are these products that > > still see active deployment (new designs) and maintenance > > in the long term (5-10 years from now)? > > > It's ok from Hilscher side. I've talked to our CEO and he is fine with > dropping it. Those boards are not produced anymore and our new Asics > (e.g. netX4000 and upcoming) will replace netX100/500 in the long term. > Our Asics usually have a guaranteed lifecycle of 10 years and netX100 > has been around since 2006, if I remember correctly, so we don't expect > many new linux projects arising, with the need for the newest kernel. > Old kernel version will still be working though. I think we also need to consider any existing installations here that have already deployed hardware but do require kernel upgrades in the future, e.g. when systems are connected to public networks and may be vulnerable to attacks. I would assume that the 10 year lifecycle is for deploying boards into the field, not the time that you expect your customers to stop using the hardware, right? Some of the SoCs that we support in mainline Linux have been EOLed by their manufacturers many years ago, but are still deployed in large numbers and get kernel updates through projects like OpenWRT or through companies like Pengutronix or Bootlin working directly with companies using them. > > OK! But when you have time and resources, please consider to > > work with the kernel community to get the board support upstream. > > > We want to work with the community now and in the future, but for > netX4000 we first needed to get this SoC working. It took many > development cycles to get all implementation working and now it seems to > have settled so we can think about step two. netX4000 Final (with all > required changes) was released end of last year. > > Main problem would have been the continuous change of the Asic during > development and more or less constant changes to kernel sources. I think > this would have caused some laughing on the mailing list if we submit a > patch one day and do it the complete other way round with the next > (possibly non-public) stepping of the Asic. Not at all, in fact our preferred way to operate is to work with hardware companies as early as possible. We definitely merge drivers for pre-production SoCs that can end up getting rewritten or even dropped completely within a short time if it turns out the hardware gets changed again or never gets sold for reasons that are not our concern. I usually suggest submitting drivers as soon as you have cleared any nontechnical obstacles (e.g. unannounced product features) and have code that looks maintainable, even if you have remaining bugs and missing features. Since SoC support is now split into many independent drivers, you can upstream each driver at its own pace, with the goal of reducing the number of patches you keep in your own tree compared to mainline. The ideal case is that all features work in a mainline kernel on the day that the first hardware gets into your customers' hands, though more commonly there will be a set of patches that take a bit longer. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Hilscher NetX mach-netx refactorings 2019-01-14 14:22 ` Linus Walleij 2019-01-15 7:05 ` Michael Trensch @ 2019-01-15 10:14 ` Arnd Bergmann 1 sibling, 0 replies; 11+ messages in thread From: Arnd Bergmann @ 2019-01-15 10:14 UTC (permalink / raw) To: Linus Walleij Cc: Ladislav Michl, Michael Trensch, nagasureshkumarrelli, Pengutronix Kernel Team, Olof Johansson, Robert Schwebel, Linux ARM On Mon, Jan 14, 2019 at 3:22 PM Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, Jan 14, 2019 at 12:26 PM Michael Trensch <MTrensch@hilscher.com> wrote: > > The netX4000 platform is only built using a device tree. The device tree > > files were sometime ago moved out of the kernel into our yocto layer to > > reduce maintenance and have a single location. I know this conflicts > > with mainlining. > > No big deal where you keep the files as long as they are merged > when we implement the platform in the upstream kernel. Agreed. It's usually best to have all reference boards working out of the box using the dts files supplied with the kernel, but for customer specific machines, we don't care much whether they are shipped with kernel or some other way (e.g. bootloader, formware or distro). Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hilscher NetX mach-netx refactorings 2019-01-12 8:35 Hilscher NetX mach-netx refactorings Linus Walleij 2019-01-12 12:03 ` Arnd Bergmann @ 2019-01-14 10:35 ` Sascha Hauer 1 sibling, 0 replies; 11+ messages in thread From: Sascha Hauer @ 2019-01-14 10:35 UTC (permalink / raw) To: Linus Walleij Cc: Olof Johansson, Robert Schwebel, Arnd Bergmann, Pengutronix Kernel Team, Linux ARM Hi Linus, On Sat, Jan 12, 2019 at 09:35:46AM +0100, Linus Walleij wrote: > Hi Sascha, Robert, > > I am looking at refactoring mach-netx to use the new PL11x > DRM driver for the graphics. > > I need to make sure that patches get tested on the hardware > and just want to ascertain that there is an active maintainer that > will be able to test patches I make for this and work on getting > it migrated to DRM before I start spending time on it. > > Are you/pengutronix still actively maintaining this machine and > testing new kernels on netx? We do not have any hardware available anymore, so no, we do not test it. Also we currently do not have any resources for maintaining netx. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-01-15 10:15 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-01-12 8:35 Hilscher NetX mach-netx refactorings Linus Walleij 2019-01-12 12:03 ` Arnd Bergmann 2019-01-13 12:14 ` Linus Walleij 2019-01-13 15:50 ` Ladislav Michl 2019-01-13 22:39 ` Linus Walleij 2019-01-14 11:26 ` Michael Trensch 2019-01-14 14:22 ` Linus Walleij 2019-01-15 7:05 ` Michael Trensch 2019-01-15 10:11 ` Arnd Bergmann 2019-01-15 10:14 ` Arnd Bergmann 2019-01-14 10:35 ` Sascha Hauer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).