* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) [not found] ` <4e07823e-7162-525a-4a61-9bed63e85d58@kaod.org> @ 2021-10-20 13:16 ` LEROY Christophe 2021-10-20 15:04 ` Simon Marchi 2021-10-28 12:24 ` Luis Machado 0 siblings, 2 replies; 4+ messages in thread From: LEROY Christophe @ 2021-10-20 13:16 UTC (permalink / raw) To: Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé Cc: Thomas Huth, Richard Henderson, Alexey Kardashevskiy, David Gibson, Peter Maydell, dbarboza, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, gdb 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-20 13:16 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) LEROY Christophe @ 2021-10-20 15:04 ` Simon Marchi 2021-10-28 12:24 ` Luis Machado 1 sibling, 0 replies; 4+ messages in thread From: Simon Marchi @ 2021-10-20 15:04 UTC (permalink / raw) To: LEROY Christophe, Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé Cc: Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, gdb, Richard Henderson, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Hervé Poussineau, David Gibson 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-20 13:16 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) LEROY Christophe 2021-10-20 15:04 ` Simon Marchi @ 2021-10-28 12:24 ` Luis Machado 2021-10-28 17:27 ` Christophe Leroy 1 sibling, 1 reply; 4+ messages in thread From: Luis Machado @ 2021-10-28 12:24 UTC (permalink / raw) To: LEROY Christophe, Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé Cc: Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, gdb, Richard Henderson, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Hervé Poussineau, David Gibson 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? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-28 12:24 ` Luis Machado @ 2021-10-28 17:27 ` Christophe Leroy 0 siblings, 0 replies; 4+ messages in thread From: Christophe Leroy @ 2021-10-28 17:27 UTC (permalink / raw) To: Luis Machado, Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé Cc: Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, gdb, Richard Henderson, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Hervé Poussineau, David Gibson 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-10-28 17:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20210927044808.73391-1-david@gibson.dropbear.id.au>
[not found] ` <20210927044808.73391-5-david@gibson.dropbear.id.au>
[not found] ` <18fa56ee-956e-ee2f-9270-82aa96dfde09@redhat.com>
[not found] ` <df767942-be5f-c920-2924-a5221e9db2b3@csgroup.eu>
[not found] ` <40cdb137-60c9-43fd-7b48-4858cbd9307c@redhat.com>
[not found] ` <CAFEAcA82L5JiHXUmc0vt7EgiiyrYHyJ+qQ7pFHp+CsvJCPyKqA@mail.gmail.com>
[not found] ` <6c2ff4e6-4bf4-d310-5e26-c8d2741177bc@redhat.com>
[not found] ` <42e5a8c2-b8fa-b9e2-71f1-c8e5cd7f5cef@csgroup.eu>
[not found] ` <1397f18f-f187-6f48-ed6c-13c0b77abed9@redhat.com>
[not found] ` <YVug7l8LWl3e+DN5@yekko>
[not found] ` <9aeb7010-0a17-864a-cfac-ea5d90356085@csgroup.eu>
[not found] ` <f0871969-190a-d15e-50d8-e6c1b1043652@ozlabs.ru>
[not found] ` <5e4f78ce-1508-5689-ec29-79edad0c824e@kaod.org>
[not found] ` <491d6265-3785-b11-b7f0-621a3d2823@eik.bme.hu>
[not found] ` <b9f27c1b-1162-b178-9333-89c0dd707c12@redhat.com>
[not found] ` <103e098a-a8ac-a22a-8aad-3df7d8cde148@amsat.org>
[not found] ` <939f2d12-38f6-4ab0-b688-384136d1d9c@eik.bme.hu>
[not found] ` <4e07823e-7162-525a-4a61-9bed63e85d58@kaod.org>
2021-10-20 13:16 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) LEROY Christophe
2021-10-20 15:04 ` Simon Marchi
2021-10-28 12:24 ` Luis Machado
2021-10-28 17:27 ` Christophe Leroy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).