Hilscher NetX mach-netx refactorings

Hilscher NetX mach-netx refactorings

[Linus Walleij]

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

Re: Hilscher NetX mach-netx refactorings

[Arnd Bergmann]

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

Re: Hilscher NetX mach-netx refactorings

[Linus Walleij]

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

Re: Hilscher NetX mach-netx refactorings

[Ladislav Michl]

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

Re: Hilscher NetX mach-netx refactorings

[Linus Walleij]

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

Re: Hilscher NetX mach-netx refactorings

[Sascha Hauer]

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

Re: Re: Hilscher NetX mach-netx refactorings

[Michael Trensch]

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

Re: Re: Hilscher NetX mach-netx refactorings

[Linus Walleij]

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

Re: Hilscher NetX mach-netx refactorings

[Michael Trensch]

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

Re: Hilscher NetX mach-netx refactorings

[Arnd Bergmann]

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

Re: Re: Hilscher NetX mach-netx refactorings

[Arnd Bergmann]

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