[RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms

[Paul Gortmaker]

[Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms] On 01/03/2023 (Wed 14:23) Christophe Leroy wrote:

> 
> 
> Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??:
> > On Tue, Feb 28, 2023, at 11:03, Joakim Tjernlund wrote:
> >> On Mon, 2023-02-27 at 14:48 -0600, Li Yang wrote:
> >>>>>>
> >>>>>> Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the
> >>>>>> MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel.
> >>>>>>
> >>>>>> There will still exist several e300 Freescale Reference Design System (RDS)
> >>>>>> boards[5] and mini-ITX boards[6] with support in the kernel.  While these
> >>>>>> were more of a COTS "ready to deploy" design more suited to hobbyists, it
> >>>>>> probably makes sense to consider removing these as well, based on age.
> >>>>>
> >>>>> These boards are mass market boards that sold in larger amount and are much more likely to still be used.  We would suggest we keep them for now.
> >>
> >> Agreed, the RDS design is still used here.
> > 
> > Can you elaborate what the typical kernel upgrade schedule for
> > these boards?
> > 
> > Note that for the debate about dropping the machines from future
> > kernels, it does not really matter how many remaining users there
> > are or how many boards get sold. The only question is whether
> > someone is still planning to provide upgrades to kernels later
> > than linux-6.3 in the future.
> > 
> > It sounds like there are commercial requirements for validating
> > and distributing kernel upgrades (in addition to hobbyist uses), so
> > I would expect that whoever is paying for the upgrades has a clear
> > plan for how much longer they are going to do that, or at least
> > a some idea of how many of the previous LTS kernels (5.10, 5.15,
> > 6.1) ended up actually getting shipped to users.
> > 
> > It may be worth pointing out that the official webpage for
> > the MPC8313ERDB board in the example only lists a hilariously
> > outdated BSP kernel based on a patched linux-2.6.23 release,
> > so maybe the marketing team can change that to point to the
> > latest validated LTS kernel instead.
> 
> Let me present things in a slightly different way.
> 
> My company has designed and manufactured and sold communication systems 
> embedding three types of boards:
> - First generation, with MPC 866, designed around 2002.
> - Second generation, with MPC 885, designed around 2010.
> - Third generation, with MPC 8321, designed around 2014.
> 
> When NXP announced end of life of MPC 866 and 885, we bought enough CPUs 
> to be able to produce boards for the 10 following years so we still 
> produce some.
> 
> MPC 8321 is still in production.
> 
> All those boards are used in critical systems where we have a customer 
> requirement to keep all software including U-boot and Linux kernel up to 
> date, for IT security reason mainly.

Firstly, thank you for the detailed reply - I totally appreciate how
framing things with this detail was not without effort on your part.

And your reasons for updating u-boot and the kernel are also valid.

> Until now, the boards were delivered with kernel 4.14, with is due to 
> EOL early next year.
> At the moment we are working on upgrading to mainline kernel with the 
> target being to be able to upgrade our customers to next LTS kernel at 
> the begining of 2024.
> 
> Note that because our kernel code is prehistoric, it is not mergeable to 
> mainline. Not because of licence issues but because the code is just not 
> following at all linux standard. So our boards are not in mainline. Two 
> of them are in U-boot and the third one should soon be as well.
> 
> So, to come back about the RDB boards, we have a couple of MPC 885 ADS 
> and a couple of MPC 8321 RDB. They are reference boards and we always 
> check that a given kernel version properly runs on them before starting 
> to port it to our hardware.

Just as a reminder - I only mentioned RDB "for consideration".  None of
the RDB platforms were removed in this series.  I don't want people to
inadvertently conflate the two.

> Hope it clarifies how those reference boards are used.

It was really useful input and gave an insight into how things get used.

But let me put a slightly different slant on things.  If there is no
maintainer for the platform/architecture/CPU, then where is the
obligation for mainline to keep it up to date just for your company to
use the code/BSP as a reference?

Do they continue to do this for one more year, or three or ...  ???
Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ?

Let us put that aside for now.  I've worked with linux-next for decade+
and have a pretty good idea how all that "upstream stuff" works.

If you have custom out-of-tree BSP and are interested in how upstream
changes impact it, you should have nightly builds pulling down
linux-next and applying your changes and finding when things break.

If you see change 0123abcdef breaks boot on your platform, you have a
legit voice to gripe about it right then and there.  Don't wait!!!

If you instead try and jump from v4.14 to v6.1 in one step, and then 
expect people to bisect on your behalf -- well good luck.

The same applies to RDB boards - doesn't matter if they are in tree or
support is applied manually.  If they are of interest to you, then track
and test regularly.  It will save you a whole lot of bisect effort.

Hope this helps,
Paul.
--

> 
> Christophe