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

[Luis Machado]

On 10/20/21 10:16 AM, LEROY Christophe wrote:
> Le 20/10/2021 à 14:43, Cédric Le Goater a écrit :
> > 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:
> > > > > On 05/10/2021 14.20, BALATON Zoltan wrote:
> > > > > > On Tue, 5 Oct 2021, Cédric Le Goater wrote:
> > > > > > > On 10/5/21 08:18, Alexey Kardashevskiy wrote:
> > > > > > > > On 05/10/2021 15:44, Christophe Leroy wrote:
> > > > > > > > > Le 05/10/2021 à 02:48, David Gibson a écrit :
> > > > > > > > > > On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
> > > > > > > > > > > On 01/10/2021 15.04, Christophe Leroy wrote:
> > > > > > > > > > > > Le 01/10/2021 à 14:04, Thomas Huth a écrit :
> > > > > > > > > > > > > On 01/10/2021 13.12, Peter Maydell wrote:
> > > > > > > > > > > > > > On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > Nevertheless, as long as nobody has a hint where to find that
> > > > > > > > > > > > > > > ppc405_rom.bin, I think both boards are pretty useless in
> > > > > > > > > > > > > > > QEMU (as far as I
> > > > > > > > > > > > > > > can see, they do not work without the bios at all, so it's
> > > > > > > > > > > > > > > also not possible
> > > > > > > > > > > > > > > to use a Linux image with the "-kernel" CLI option directly).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It is at least in theory possible to run bare-metal code on
> > > > > > > > > > > > > > either board, by passing either a pflash or a bios argument.
> > > > > > > > > > > > >
> > > > > > > > > > > > > True. I did some more research, and seems like there was once
> > > > > > > > > > > > > support for those boards in u-boot, but it got removed there a
> > > > > > > > > > > > > couple of years ago already:
> > > > > > > > > > > > >
> > > > > > > > > > > > > https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
> > > > > > > > > > > > >
> > > > > > > > > > > > > https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
> > > > > > > > > > > > >
> > > > > > > > > > > > > https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
> > > > > > > > > > > > >
> > > > > > > > > > > > > > But I agree that there seem to be no signs of anybody actually
> > > > > > > > > > > > > > successfully using these boards for anything, so we should
> > > > > > > > > > > > > > deprecate-and-delete them.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, let's mark them as deprecated now ... if someone still
> > > > > > > > > > > > > uses
> > > > > > > > > > > > > them and speaks up, we can still revert the deprecation again.
> > > > > > > > > > > >
> > > > > > > > > > > > I really would like to be able to use them to validate Linux
> > > > > > > > > > > > Kernel
> > > > > > > > > > > > changes, hence looking for that missing BIOS.
> > > > > > > > > > > >
> > > > > > > > > > > > If we remove ppc405 from QEMU, we won't be able to do any
> > > > > > > > > > > > regression
> > > > > > > > > > > > tests of Linux Kernel on those processors.
> > > > > > > > > > >
> > > > > > > > > > > If you/someone managed to compile an old version of u-boot for
> > > > > > > > > > > one of these
> > > > > > > > > > > two boards, so that we would finally have something for
> > > > > > > > > > > regression testing,
> > > > > > > > > > > we can of course also keep the boards in QEMU...
> > > > > > > > > >
> > > > > > > > > > I can see that it would be usefor for some cases, but unless
> > > > > > > > > > someone
> > > > > > > > > > volunteers to track down the necessary firmware and look after
> > > > > > > > > > it, I
> > > > > > > > > > think we do need to deprecate it - I certainly don't have the
> > > > > > > > > > capacity
> > > > > > > > > > to look into this.
> > > > > > > > >
> > > > > > > > > I will look at it, please allow me a few weeks though.
> > > > > > > >
> > > > > > > > Well, building it was not hard but now I'd like to know what board
> > > > > > > > QEMU actually emulates, there are way too many codenames and PVRs.
> > > > > > >
> > > > > > > yes. We should try to reduce the list below. Deprecating embedded
> > > > > > > machines
> > > > > > > is one way.
> > > > > >
> > > > > > Why should we reduce that list? It's good to have different cpu
> > > > > > options when one wants to test code for different PPC versions (maybe
> > > > > > also in user mode) or just to have a quick list of these at one place.
> > > > >
> > > > > 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
> > 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
> > strictly necessary. It depends if Linux relies on it to do some
> > pre-initialization of HW. I guess once we find a good DTS for it, or
> > not, we can take a decision.
>
> I now have a hacked configuration booting linux with the hotfoot DTS and
> the kernel is booting up to starting /init
>
> Then it is faulting forever taking a DSI for write protection. The
> problem is now likely in Linux and I'm investigating it, but I'm having
> problem with GDB (7.8.1), I'm hitting the bug
> https://sourceware.org/bugzilla/show_bug.cgi?id=17700
>
> And GDB 11.1 coredumps while reading vmlinux's symbols
>
> Hopefully I'll find a GDB version between 7.8 and 11 that works.

Just to confirm, you're not really having problems with the ARM port of 
GDB, right? It is a 32-bit PowerPC one. The bug you pointed out is only 
a reference to a similar one for PowerPC?