Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[BALATON Zoltan]

On Wed, 20 Oct 2021, Cédric Le Goater wrote:
> On 10/20/21 13:42, BALATON Zoltan wrote:
> > On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
> > > On 10/5/21 14:29, Thomas Huth wrote:
> > > > I think there are many CPUs in that list which cannot be used with any
> > > > board, some of them might be also in a very incomplete state. So
> > > > presenting such a big list to the users is confusing and might create
> > > > wrong expectations. It would be good to remove at least the CPUs which
> > > > are really completely useless.
> > >
> > > Maybe only remove some from system emulation but keep all of them
> > > in user emulation?
> >
> > Or keep them all but mark those that are not tested/may be incomplete? So 
> > the used can see what is expected to work and what may need to be fixed. 
> > That way somebody may try and fix it whereas if it's not there they are 
> > unlikely to try to add it.
>
>
> The bamboo machine with 440 CPUs is booting with the latest kernel
> and we have an acceptance test for it now, thanks to Thomas. There

We also have the sam460ex for 440 based CPU that runs with Linux as 
another test but having more than one is better and not sure if the 
sam460ex has an acceptance test in QEMU. (I think Guenter Roeck tests 
sam460ex with Linux at least he did in the past.)

By the way what happened to the test written by Philippe for pegasos2. Is 
that upstream yet? That test used MorphOS so we don't only test Linux (but 
it needs the iso which is freely downloadable but probably not 
redistributable due to its license). And that's not a BookE CPU so maybe 
off-topic in this thtead I was just reminded of it.

> is not much effort in keeping them in a working state until someone
> volunteers. Hopefully, Christophe is making sure that we are not
> breaking anything with Linux support.
>
> The 405 machine are still close to deprecation I think. We are still
> struggling to boot one with mainline Linux, using uboot provided by
> Thomas which skips SDRAM init. It is not clear to me if u-boot is

I think the SDRAM init could be fixed by adding SPD data, I've done that 
for sam460ex, I may try to look at cleaning up the memory controller 
models together with the 440 one as these are similar but not too high on 
my list I want to do now so maybe later if 405 will be kept.

Regards,
BALATON Zoltan