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

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

[LEROY Christophe]

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.

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

[Simon Marchi]

On 2021-10-20 9:16 a.m., LEROY Christophe wrote:
> And GDB 11.1 coredumps while reading vmlinux's symbols
> 
> Hopefully I'll find a GDB version between 7.8 and 11 that works.

That's not cool.  Could you file a bug for it?  If you could share your
vmlinux executable (or steps to re-create it, with details about compiler
version and all), that would be very helpful.

Thanks,

Simon

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?

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

[Christophe Leroy]

Le 28/10/2021 à 14:24, Luis Machado a écrit :
> 
> 
> 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?

That's correct, saw the same problem on PowerPC.

I added a comment in bugzilla.

Christophe