| Message ID | 20210927044808.73391-5-david@gibson.dropbear.id.au (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Reduce load on ppc target maintainers | expand |
On 27/09/2021 06.48, David Gibson wrote: > There are a nunber of old embedded ppc machine types which have been little > changed and in "Odd Fixes" state for a long time. With both myself and > Greg Kurz moving toward other areas, we no longer have the capacity to > keep reviewing and maintaining even the rare patches that come in for those > platforms. > > Therefore, remove our names as reviewers and mark these platforms as > orphaned. > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au> > Reviewed-by: Greg Kurz <groug@kaod.org> > Reviewed-by: Cédric Le Goater <clg@kaod.org> > --- > MAINTAINERS | 19 +++++-------------- > 1 file changed, 5 insertions(+), 14 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index f2060b46f9..1ecb5716c8 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1236,24 +1236,18 @@ F: hw/openrisc/openrisc_sim.c > PowerPC Machines > ---------------- > 405 > -M: David Gibson <david@gibson.dropbear.id.au> > -M: Greg Kurz <groug@kaod.org> > L: qemu-ppc@nongnu.org > -S: Odd Fixes > +S: Orphan > F: hw/ppc/ppc405_boards.c Related question: Does *anybody* know how to still use the ref405ep or taihu board in QEMU? We just got another ticket asking for the related firmware image: https://gitlab.com/qemu-project/qemu/-/issues/651 And if you google for 'ppc405_rom.bin', I only find pages where people are asking basically the same question, e.g.: https://lists.nongnu.org/archive/html/qemu-devel/2007-08/msg00252.html (in 2007 already! And no answer) https://github.com/Xilinx/qemu/issues/36 (in 2019, no answer) https://lists.libreplanet.org/archive/html/qemu-ppc/2019-12/msg00263.html (in 2019, no answer about bios location) https://lkml.org/lkml/2020/4/25/61 (in 2020, no answer) Seems like the Linux kernel removed support for the 405ep board here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=548f5244f1064c9facb19c5e9 ... to me this all sounds like these 405 boards are pretty dead code in QEMU right now, so if nobody has a clue how to use them, I'd suggest to mark them as deprecated and remove them in a couple of releases? Thomas
Le 01/10/2021 à 10:35, Thomas Huth a écrit : > On 27/09/2021 06.48, David Gibson wrote: >> There are a nunber of old embedded ppc machine types which have been >> little >> changed and in "Odd Fixes" state for a long time. With both myself and >> Greg Kurz moving toward other areas, we no longer have the capacity to >> keep reviewing and maintaining even the rare patches that come in for >> those >> platforms. >> >> Therefore, remove our names as reviewers and mark these platforms as >> orphaned. >> >> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> >> Reviewed-by: Greg Kurz <groug@kaod.org> >> Reviewed-by: Cédric Le Goater <clg@kaod.org> >> --- >> MAINTAINERS | 19 +++++-------------- >> 1 file changed, 5 insertions(+), 14 deletions(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index f2060b46f9..1ecb5716c8 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -1236,24 +1236,18 @@ F: hw/openrisc/openrisc_sim.c >> PowerPC Machines >> ---------------- >> 405 >> -M: David Gibson <david@gibson.dropbear.id.au> >> -M: Greg Kurz <groug@kaod.org> >> L: qemu-ppc@nongnu.org >> -S: Odd Fixes >> +S: Orphan >> F: hw/ppc/ppc405_boards.c > > Related question: Does *anybody* know how to still use the ref405ep or > taihu board in QEMU? We just got another ticket asking for the related > firmware image: > > https://gitlab.com/qemu-project/qemu/-/issues/651 > > And if you google for 'ppc405_rom.bin', I only find pages where people > are asking basically the same question, e.g.: > > https://lists.nongnu.org/archive/html/qemu-devel/2007-08/msg00252.html > (in 2007 already! And no answer) > > https://github.com/Xilinx/qemu/issues/36 (in 2019, no answer) > > https://lists.libreplanet.org/archive/html/qemu-ppc/2019-12/msg00263.html (in 2019, no answer about bios location) > > https://lkml.org/lkml/2020/4/25/61 (in 2020, no answer) > > > Seems like the Linux kernel removed support for the 405ep board here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=548f5244f1064c9facb19c5e9 > The EP405 board was removed because it was apparently based on the buggy 405GP processor (It was selecting option CONFIG_405GP). AFAIU the EP405 board is different from the ref405ep. The ref405ep has a 405EP processor which is still supported, see https://elixir.bootlin.com/linux/v5.15-rc3/source/arch/powerpc/kernel/cputable.c#L1300 Christophe > > ... to me this all sounds like these 405 boards are pretty dead code in > QEMU right now, so if nobody has a clue how to use them, I'd suggest to > mark them as deprecated and remove them in a couple of releases? >
On 01/10/2021 11.14, Christophe Leroy wrote: > > > Le 01/10/2021 à 10:35, Thomas Huth a écrit : >> On 27/09/2021 06.48, David Gibson wrote: >>> There are a nunber of old embedded ppc machine types which have been little >>> changed and in "Odd Fixes" state for a long time. With both myself and >>> Greg Kurz moving toward other areas, we no longer have the capacity to >>> keep reviewing and maintaining even the rare patches that come in for those >>> platforms. >>> >>> Therefore, remove our names as reviewers and mark these platforms as >>> orphaned. >>> >>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> >>> Reviewed-by: Greg Kurz <groug@kaod.org> >>> Reviewed-by: Cédric Le Goater <clg@kaod.org> >>> --- >>> MAINTAINERS | 19 +++++-------------- >>> 1 file changed, 5 insertions(+), 14 deletions(-) >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index f2060b46f9..1ecb5716c8 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -1236,24 +1236,18 @@ F: hw/openrisc/openrisc_sim.c >>> PowerPC Machines >>> ---------------- >>> 405 >>> -M: David Gibson <david@gibson.dropbear.id.au> >>> -M: Greg Kurz <groug@kaod.org> >>> L: qemu-ppc@nongnu.org >>> -S: Odd Fixes >>> +S: Orphan >>> F: hw/ppc/ppc405_boards.c >> >> Related question: Does *anybody* know how to still use the ref405ep or >> taihu board in QEMU? We just got another ticket asking for the related >> firmware image: >> >> https://gitlab.com/qemu-project/qemu/-/issues/651 >> >> And if you google for 'ppc405_rom.bin', I only find pages where people are >> asking basically the same question, e.g.: >> >> https://lists.nongnu.org/archive/html/qemu-devel/2007-08/msg00252.html >> (in 2007 already! And no answer) >> >> https://github.com/Xilinx/qemu/issues/36 (in 2019, no answer) >> >> https://lists.libreplanet.org/archive/html/qemu-ppc/2019-12/msg00263.html (in >> 2019, no answer about bios location) >> >> https://lkml.org/lkml/2020/4/25/61 (in 2020, no answer) >> >> >> Seems like the Linux kernel removed support for the 405ep board here: >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=548f5244f1064c9facb19c5e9 >> > > The EP405 board was removed because it was apparently based on the buggy > 405GP processor (It was selecting option CONFIG_405GP). > > AFAIU the EP405 board is different from the ref405ep. The ref405ep has a > 405EP processor which is still supported, see > https://elixir.bootlin.com/linux/v5.15-rc3/source/arch/powerpc/kernel/cputable.c#L1300 Oh, that's pretty confusing, thank a lot for the clarification! 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). Thomas
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. 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. -- PMM
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. Thomas
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. Christophe
On 10/1/21 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. It's nice to have I agree. Someone needs to find the right u-boot level and certainly also, a host old enough to support the compiler options. May be, a RH6 ppc64 VM or an old ppc32 debian image running under QEMU or some MAC. Tell me if you need some help to get a system/image. C.
On Fri, 1 Oct 2021 at 14:04, Christophe Leroy <christophe.leroy@csgroup.eu> wrote: > 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. Do you (does anyone) have real hardware to test against? If the only thing you have is QEMU's emulation, I wouldn't particularly trust it to be bug-free enough to keep the kernel still working on real h/w... -- PMM
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... Thomas
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.
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. Thanks Christophe
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. Here is what I was building: https://github.com/aik/u-boot/tree/ppc4xx-qemu CONFIG_SYS_ARCH="powerpc" CONFIG_SYS_CPU="ppc4xx" CONFIG_SYS_VENDOR="esd" CONFIG_SYS_BOARD="pmc405de" CONFIG_SYS_CONFIG_NAME="PMC405DE" Is this any use?
On 05/10/2021 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. > > Here is what I was building: > https://github.com/aik/u-boot/tree/ppc4xx-qemu > > CONFIG_SYS_ARCH="powerpc" > CONFIG_SYS_CPU="ppc4xx" > CONFIG_SYS_VENDOR="esd" > CONFIG_SYS_BOARD="pmc405de" > CONFIG_SYS_CONFIG_NAME="PMC405DE" > > Is this any use? If I've got u-boot commit 98f705c9cefdfdba62c069821bbba10273a0a8 right, there used to be SYS_BOARD="405ep" config before that removal, so that sounds like a promising match for the ref405ep of QEMU? The support for "taihu" even got removed earlier, in u-boot commit 123b6cd7a4f75536734a7bff97db6eebce614bd1 , and the commit message says that it did not compile anymore at the end, so you might need to check out an even older version for that one. Thomas
On 05/10/2021 17:42, Thomas Huth wrote: > On 05/10/2021 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. >> >> Here is what I was building: >> https://github.com/aik/u-boot/tree/ppc4xx-qemu >> >> CONFIG_SYS_ARCH="powerpc" >> CONFIG_SYS_CPU="ppc4xx" >> CONFIG_SYS_VENDOR="esd" >> CONFIG_SYS_BOARD="pmc405de" >> CONFIG_SYS_CONFIG_NAME="PMC405DE" >> >> Is this any use? > > If I've got u-boot commit 98f705c9cefdfdba62c069821bbba10273a0a8 > right, there used to be SYS_BOARD="405ep" config before that removal, so > that sounds like a promising match for the ref405ep of QEMU? Tricky. The board can be 405ep if TARGET_IO/TARGET_DLVISION/TARGET_DLVISION_10G selected. Neither compiles at 98f705c9cefdfdba62c^ due to missing CONFIG_SYS_PCI_PTM1PCI :-/ > > The support for "taihu" even got removed earlier, in u-boot commit > 123b6cd7a4f75536734a7bff97db6eebce614bd1 , and the commit message says > that it did not compile anymore at the end, so you might need to check > out an even older version for that one. What is so special about taihu?
On 05/10/2021 10.05, Alexey Kardashevskiy wrote: > > > On 05/10/2021 17:42, Thomas Huth wrote: >> On 05/10/2021 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. >>> >>> Here is what I was building: >>> https://github.com/aik/u-boot/tree/ppc4xx-qemu >>> >>> CONFIG_SYS_ARCH="powerpc" >>> CONFIG_SYS_CPU="ppc4xx" >>> CONFIG_SYS_VENDOR="esd" >>> CONFIG_SYS_BOARD="pmc405de" >>> CONFIG_SYS_CONFIG_NAME="PMC405DE" >>> >>> Is this any use? >> >> If I've got u-boot commit 98f705c9cefdfdba62c069821bbba10273a0a8 >> right, there used to be SYS_BOARD="405ep" config before that removal, so >> that sounds like a promising match for the ref405ep of QEMU? > > Tricky. The board can be 405ep if > TARGET_IO/TARGET_DLVISION/TARGET_DLVISION_10G selected. Neither compiles at > 98f705c9cefdfdba62c^ due to missing CONFIG_SYS_PCI_PTM1PCI :-/ > >> >> The support for "taihu" even got removed earlier, in u-boot commit >> 123b6cd7a4f75536734a7bff97db6eebce614bd1 , and the commit message says >> that it did not compile anymore at the end, so you might need to check out >> an even older version for that one. > > > What is so special about taihu? taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I suggested to deprecate now) Thomas
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. C. $ ./install/bin/qemu-system-ppc -cpu ? PowerPC 601_v0 PVR 00010001 PowerPC 601_v1 PVR 00010001 PowerPC 601_v2 PVR 00010002 PowerPC 601 (alias for 601_v2) PowerPC 601v (alias for 601_v2) PowerPC 603 PVR 00030100 PowerPC mpc8240 (alias for 603) PowerPC vanilla (alias for 603) PowerPC 604 PVR 00040103 PowerPC ppc32 (alias for 604) PowerPC ppc (alias for 604) PowerPC default (alias for 604) PowerPC 602 PVR 00050100 PowerPC 603e_v1.1 PVR 00060101 PowerPC 603e_v1.2 PVR 00060102 PowerPC 603e_v1.3 PVR 00060103 PowerPC 603e_v1.4 PVR 00060104 PowerPC 603e_v2.2 PVR 00060202 PowerPC 603e_v3 PVR 00060300 PowerPC 603e_v4 PVR 00060400 PowerPC 603e_v4.1 PVR 00060401 PowerPC 603e (alias for 603e_v4.1) PowerPC stretch (alias for 603e_v4.1) PowerPC 603p PVR 00070000 PowerPC 603e7v PVR 00070100 PowerPC vaillant (alias for 603e7v) PowerPC 603e7v1 PVR 00070101 PowerPC 603e7 PVR 00070200 PowerPC 603e7v2 PVR 00070201 PowerPC 603e7t PVR 00071201 PowerPC 603r (alias for 603e7t) PowerPC goldeneye (alias for 603e7t) PowerPC 740_v1.0 PVR 00080100 PowerPC 740e PVR 00080100 PowerPC 750_v1.0 PVR 00080100 PowerPC 750_v2.0 PVR 00080200 PowerPC 740_v2.0 PVR 00080200 PowerPC 750e PVR 00080200 PowerPC 750_v2.1 PVR 00080201 PowerPC 740_v2.1 PVR 00080201 PowerPC 750_v2.2 PVR 00080202 PowerPC 740_v2.2 PVR 00080202 PowerPC 750_v3.0 PVR 00080300 PowerPC 740_v3.0 PVR 00080300 PowerPC 750_v3.1 PVR 00080301 PowerPC 750 (alias for 750_v3.1) PowerPC typhoon (alias for 750_v3.1) PowerPC g3 (alias for 750_v3.1) PowerPC 740_v3.1 PVR 00080301 PowerPC 740 (alias for 740_v3.1) PowerPC arthur (alias for 740_v3.1) PowerPC 750cx_v1.0 PVR 00082100 PowerPC 750cx_v2.0 PVR 00082200 PowerPC 750cx_v2.1 PVR 00082201 PowerPC 750cx_v2.2 PVR 00082202 PowerPC 750cx (alias for 750cx_v2.2) PowerPC 750cxe_v2.1 PVR 00082211 PowerPC 750cxe_v2.2 PVR 00082212 PowerPC 750cxe_v2.3 PVR 00082213 PowerPC 750cxe_v2.4 PVR 00082214 PowerPC 750cxe_v3.0 PVR 00082310 PowerPC 750cxe_v3.1 PVR 00082311 PowerPC 745_v1.0 PVR 00083100 PowerPC 755_v1.0 PVR 00083100 PowerPC 755_v1.1 PVR 00083101 PowerPC 745_v1.1 PVR 00083101 PowerPC 755_v2.0 PVR 00083200 PowerPC 745_v2.0 PVR 00083200 PowerPC 755_v2.1 PVR 00083201 PowerPC 745_v2.1 PVR 00083201 PowerPC 755_v2.2 PVR 00083202 PowerPC 745_v2.2 PVR 00083202 PowerPC 755_v2.3 PVR 00083203 PowerPC 745_v2.3 PVR 00083203 PowerPC 755_v2.4 PVR 00083204 PowerPC 745_v2.4 PVR 00083204 PowerPC 755_v2.5 PVR 00083205 PowerPC 745_v2.5 PVR 00083205 PowerPC 755_v2.6 PVR 00083206 PowerPC 745_v2.6 PVR 00083206 PowerPC 755_v2.7 PVR 00083207 PowerPC 745_v2.7 PVR 00083207 PowerPC 745_v2.8 PVR 00083208 PowerPC 745 (alias for 745_v2.8) PowerPC 755_v2.8 PVR 00083208 PowerPC 755 (alias for 755_v2.8) PowerPC goldfinger (alias for 755_v2.8) PowerPC 750cxe_v2.4b PVR 00083214 PowerPC 750cxe_v3.1b PVR 00083311 PowerPC 750cxe (alias for 750cxe_v3.1b) PowerPC 750cxr PVR 00083410 PowerPC 750cl_v1.0 PVR 00087200 PowerPC 750cl_v2.0 PVR 00087210 PowerPC 750cl (alias for 750cl_v2.0) PowerPC 750l_v2.0 PVR 00088200 PowerPC 750l_v2.1 PVR 00088201 PowerPC 750l_v2.2 PVR 00088202 PowerPC 750l_v3.0 PVR 00088300 PowerPC 750l_v3.2 PVR 00088302 PowerPC 750l (alias for 750l_v3.2) PowerPC lonestar (alias for 750l_v3.2) PowerPC 604e_v1.0 PVR 00090100 PowerPC 604e_v2.2 PVR 00090202 PowerPC 604e_v2.4 PVR 00090204 PowerPC 604e (alias for 604e_v2.4) PowerPC sirocco (alias for 604e_v2.4) PowerPC 604r PVR 000a0101 PowerPC mach5 (alias for 604r) PowerPC 7400_v1.0 PVR 000c0100 PowerPC 7400_v1.1 PVR 000c0101 PowerPC 7400_v2.0 PVR 000c0200 PowerPC 7400_v2.1 PVR 000c0201 PowerPC 7400_v2.2 PVR 000c0202 PowerPC 7400_v2.6 PVR 000c0206 PowerPC 7400_v2.7 PVR 000c0207 PowerPC 7400_v2.8 PVR 000c0208 PowerPC 7400_v2.9 PVR 000c0209 PowerPC 7400 (alias for 7400_v2.9) PowerPC max (alias for 7400_v2.9) PowerPC g4 (alias for 7400_v2.9) PowerPC 403ga PVR 00200011 PowerPC 403gb PVR 00200100 PowerPC 403gc PVR 00200200 PowerPC 403 (alias for 403gc) PowerPC 403gcx PVR 00201400 PowerPC 401a1 PVR 00210000 PowerPC 401b2 PVR 00220000 PowerPC iop480 PVR 00220000 PowerPC 401c2 PVR 00230000 PowerPC 401d2 PVR 00240000 PowerPC 401e2 PVR 00250000 PowerPC 401f2 PVR 00260000 PowerPC 401g2 PVR 00270000 PowerPC 401 PVR 00270000 PowerPC g2 PVR 00810011 PowerPC mpc603 PVR 00810100 PowerPC g2hip3 PVR 00810101 PowerPC mpc8250_hip3 (alias for g2hip3) PowerPC mpc8255_hip3 (alias for g2hip3) PowerPC mpc8260_hip3 (alias for g2hip3) PowerPC mpc8264_hip3 (alias for g2hip3) PowerPC mpc8265_hip3 (alias for g2hip3) PowerPC mpc8266_hip3 (alias for g2hip3) PowerPC mpc8343 PVR 00830010 PowerPC mpc8349a PVR 00830010 PowerPC mpc8347at PVR 00830010 PowerPC mpc8347a (alias for mpc8347at) PowerPC e300c1 PVR 00830010 PowerPC mpc8343ea PVR 00830010 PowerPC mpc8349e PVR 00830010 PowerPC mpc8347ep PVR 00830010 PowerPC mpc8347p PVR 00830010 PowerPC mpc8347eap PVR 00830010 PowerPC mpc8349 PVR 00830010 PowerPC mpc8347et PVR 00830010 PowerPC mpc8347e (alias for mpc8347et) PowerPC mpc8347t PVR 00830010 PowerPC mpc8347 (alias for mpc8347t) PowerPC mpc8343a PVR 00830010 PowerPC mpc8347eat PVR 00830010 PowerPC mpc8347ea (alias for mpc8347eat) PowerPC mpc8347ap PVR 00830010 PowerPC mpc8349ea PVR 00830010 PowerPC mpc8343e PVR 00830010 PowerPC e300c2 PVR 00840010 PowerPC e300c3 PVR 00850010 PowerPC e300 (alias for e300c3) PowerPC mpc8379e PVR 00860010 PowerPC e300c4 PVR 00860010 PowerPC mpc8377e PVR 00860010 PowerPC mpc8377 PVR 00860010 PowerPC mpc8378 PVR 00860010 PowerPC mpc8379 PVR 00860010 PowerPC mpc8378e PVR 00860010 PowerPC 740p PVR 10080000 PowerPC 750p PVR 10080000 PowerPC conan/doyle (alias for 750p) PowerPC cobra PVR 10100000 PowerPC 460exb PVR 130218a4 PowerPC 460ex (alias for 460exb) PowerPC 440epx PVR 200008d0 PowerPC 405d2 PVR 20010000 PowerPC x2vp4 PVR 20010820 PowerPC x2vp7 (alias for x2vp4) PowerPC x2vp20 PVR 20010860 PowerPC x2vp50 (alias for x2vp20) PowerPC 405gpa PVR 40110000 PowerPC 405gpb PVR 40110040 PowerPC 405cra PVR 40110041 PowerPC 405gpc PVR 40110082 PowerPC 405gpd PVR 401100c4 PowerPC 405gp (alias for 405gpd) PowerPC 405crb PVR 401100c5 PowerPC 405crc PVR 40110145 PowerPC 405cr (alias for 405crc) PowerPC 405gpe (alias for 405crc) PowerPC stb03 PVR 40310000 PowerPC npe4gs3 PVR 40b10000 PowerPC npe405h PVR 414100c0 PowerPC npe405h2 PVR 41410140 PowerPC 405ez PVR 41511460 PowerPC npe405l PVR 416100c0 PowerPC stb04 PVR 41810000 PowerPC 405d4 PVR 41810000 PowerPC 405 (alias for 405d4) PowerPC 405lp PVR 41f10000 PowerPC 440epa PVR 42221850 PowerPC 440epb PVR 422218d3 PowerPC 440ep (alias for 440epb) PowerPC 405gpr PVR 50910951 PowerPC 405ep PVR 51210950 PowerPC stb25 PVR 51510950 PowerPC 750fx_v1.0 PVR 70000100 PowerPC 750fx_v2.0 PVR 70000200 PowerPC 750fx_v2.1 PVR 70000201 PowerPC 750fx_v2.2 PVR 70000202 PowerPC 750fx_v2.3 PVR 70000203 PowerPC 750fx (alias for 750fx_v2.3) PowerPC 750fl PVR 70000203 PowerPC 750gx_v1.0 PVR 70020100 PowerPC 750gx_v1.1 PVR 70020101 PowerPC 750gl PVR 70020102 PowerPC 750gx_v1.2 PVR 70020102 PowerPC 750gx (alias for 750gx_v1.2) PowerPC 440-xilinx-w-dfpu PVR 7ff21910 PowerPC 440-xilinx PVR 7ff21910 PowerPC 7450_v1.0 PVR 80000100 PowerPC 7450_v1.1 PVR 80000101 PowerPC 7450_v1.2 PVR 80000102 PowerPC 7450_v2.0 PVR 80000200 PowerPC 7441_v2.1 PVR 80000201 PowerPC 7450_v2.1 PVR 80000201 PowerPC 7450 (alias for 7450_v2.1) PowerPC vger (alias for 7450_v2.1) PowerPC 7451_v2.3 PVR 80000203 PowerPC 7451 (alias for 7451_v2.3) PowerPC 7441_v2.3 PVR 80000203 PowerPC 7441 (alias for 7441_v2.3) PowerPC 7451_v2.10 PVR 80000210 PowerPC 7441_v2.10 PVR 80000210 PowerPC 7455_v1.0 PVR 80010100 PowerPC 7445_v1.0 PVR 80010100 PowerPC 7445_v2.1 PVR 80010201 PowerPC 7455_v2.1 PVR 80010201 PowerPC 7455_v3.2 PVR 80010302 PowerPC 7455 (alias for 7455_v3.2) PowerPC apollo6 (alias for 7455_v3.2) PowerPC 7445_v3.2 PVR 80010302 PowerPC 7445 (alias for 7445_v3.2) PowerPC 7455_v3.3 PVR 80010303 PowerPC 7445_v3.3 PVR 80010303 PowerPC 7455_v3.4 PVR 80010304 PowerPC 7445_v3.4 PVR 80010304 PowerPC 7447_v1.0 PVR 80020100 PowerPC 7457_v1.0 PVR 80020100 PowerPC 7447_v1.1 PVR 80020101 PowerPC 7447 (alias for 7447_v1.1) PowerPC 7457_v1.1 PVR 80020101 PowerPC 7457_v1.2 PVR 80020102 PowerPC 7457 (alias for 7457_v1.2) PowerPC apollo7 (alias for 7457_v1.2) PowerPC 7457a_v1.0 PVR 80030100 PowerPC apollo7pm (alias for 7457a_v1.0) PowerPC 7447a_v1.0 PVR 80030100 PowerPC 7457a_v1.1 PVR 80030101 PowerPC 7447a_v1.1 PVR 80030101 PowerPC 7457a_v1.2 PVR 80030102 PowerPC 7457a (alias for 7457a_v1.2) PowerPC 7447a_v1.2 PVR 80030102 PowerPC 7447a (alias for 7447a_v1.2) PowerPC mpc8641d PVR 80040010 PowerPC mpc8610 PVR 80040010 PowerPC e600 PVR 80040010 PowerPC mpc8641 PVR 80040010 PowerPC 7448_v1.0 PVR 80040100 PowerPC 7448_v1.1 PVR 80040101 PowerPC 7448_v2.0 PVR 80040200 PowerPC 7448_v2.1 PVR 80040201 PowerPC 7448 (alias for 7448_v2.1) PowerPC 7410_v1.0 PVR 800c1100 PowerPC 7410_v1.1 PVR 800c1101 PowerPC 7410_v1.2 PVR 800c1102 PowerPC 7410_v1.3 PVR 800c1103 PowerPC 7410_v1.4 PVR 800c1104 PowerPC 7410 (alias for 7410_v1.4) PowerPC nitro (alias for 7410_v1.4) PowerPC mpc8540_v10 PVR 80200010 PowerPC e500_v10 PVR 80200010 PowerPC mpc8541_v10 PVR 80200020 PowerPC mpc8541_v11 PVR 80200020 PowerPC mpc8541 (alias for mpc8541_v11) PowerPC mpc8541e_v10 PVR 80200020 PowerPC mpc8540_v20 PVR 80200020 PowerPC mpc8541e_v11 PVR 80200020 PowerPC mpc8541e (alias for mpc8541e_v11) PowerPC mpc8540_v21 PVR 80200020 PowerPC mpc8540 (alias for mpc8540_v21) PowerPC e500_v20 PVR 80200020 PowerPC e500v1 (alias for e500_v20) PowerPC mpc8543e_v10 PVR 80210010 PowerPC mpc8543_v10 PVR 80210010 PowerPC mpc8548e_v10 PVR 80210010 PowerPC mpc8555_v10 PVR 80210010 PowerPC mpc8555e_v10 PVR 80210010 PowerPC e500v2_v10 PVR 80210010 PowerPC mpc8560_v10 PVR 80210010 PowerPC mpc8548_v10 PVR 80210010 PowerPC mpc8543e_v11 PVR 80210011 PowerPC mpc8548e_v11 PVR 80210011 PowerPC mpc8543_v11 PVR 80210011 PowerPC mpc8555_v11 PVR 80210011 PowerPC mpc8555 (alias for mpc8555_v11) PowerPC mpc8555e_v11 PVR 80210011 PowerPC mpc8555e (alias for mpc8555e_v11) PowerPC mpc8548_v11 PVR 80210011 PowerPC mpc8560_v20 PVR 80210020 PowerPC mpc8548_v20 PVR 80210020 PowerPC mpc8547e_v20 PVR 80210020 PowerPC mpc8545_v20 PVR 80210020 PowerPC mpc8543e_v20 PVR 80210020 PowerPC mpc8548e_v20 PVR 80210020 PowerPC mpc8543_v20 PVR 80210020 PowerPC mpc8545e_v20 PVR 80210020 PowerPC e500v2_v20 PVR 80210020 PowerPC mpc8545e_v21 PVR 80210021 PowerPC mpc8545e (alias for mpc8545e_v21) PowerPC mpc8544_v10 PVR 80210021 PowerPC mpc8560_v21 PVR 80210021 PowerPC mpc8560 (alias for mpc8560_v21) PowerPC mpc8533e_v10 PVR 80210021 PowerPC mpc8544e_v10 PVR 80210021 PowerPC mpc8547e_v21 PVR 80210021 PowerPC mpc8547e (alias for mpc8547e_v21) PowerPC mpc8548_v21 PVR 80210021 PowerPC mpc8548 (alias for mpc8548_v21) PowerPC mpc8545_v21 PVR 80210021 PowerPC mpc8545 (alias for mpc8545_v21) PowerPC mpc8543e_v21 PVR 80210021 PowerPC mpc8543e (alias for mpc8543e_v21) PowerPC mpc8543_v21 PVR 80210021 PowerPC mpc8543 (alias for mpc8543_v21) PowerPC mpc8548e_v21 PVR 80210021 PowerPC mpc8548e (alias for mpc8548e_v21) PowerPC e500v2_v21 PVR 80210021 PowerPC mpc8533_v10 PVR 80210021 PowerPC mpc8544_v11 PVR 80210022 PowerPC mpc8544 (alias for mpc8544_v11) PowerPC mpc8568e PVR 80210022 PowerPC mpc8533e_v11 PVR 80210022 PowerPC mpc8533e (alias for mpc8533e_v11) PowerPC mpc8544e_v11 PVR 80210022 PowerPC mpc8544e (alias for mpc8544e_v11) PowerPC mpc8567 PVR 80210022 PowerPC mpc8568 PVR 80210022 PowerPC mpc8567e PVR 80210022 PowerPC e500v2_v22 PVR 80210022 PowerPC e500 (alias for e500v2_v22) PowerPC e500v2 (alias for e500v2_v22) PowerPC mpc8533_v11 PVR 80210022 PowerPC mpc8533 (alias for mpc8533_v11) PowerPC mpc8572e PVR 80210030 PowerPC e500v2_v30 PVR 80210030 PowerPC mpc8572 PVR 80210030 PowerPC e500mc PVR 80230020 PowerPC g2h4 PVR 80811010 PowerPC g2hip4 PVR 80811014 PowerPC mpc8241 (alias for g2hip4) PowerPC mpc8245 (alias for g2hip4) PowerPC mpc8250 (alias for g2hip4) PowerPC mpc8250_hip4 (alias for g2hip4) PowerPC mpc8255 (alias for g2hip4) PowerPC mpc8255_hip4 (alias for g2hip4) PowerPC mpc8260 (alias for g2hip4) PowerPC mpc8260_hip4 (alias for g2hip4) PowerPC mpc8264 (alias for g2hip4) PowerPC mpc8264_hip4 (alias for g2hip4) PowerPC mpc8265 (alias for g2hip4) PowerPC mpc8265_hip4 (alias for g2hip4) PowerPC mpc8266 (alias for g2hip4) PowerPC mpc8266_hip4 (alias for g2hip4) PowerPC g2le PVR 80820010 PowerPC g2gp PVR 80821010 PowerPC g2legp PVR 80822010 PowerPC mpc5200b_v20 PVR 80822011 PowerPC mpc5200_v10 PVR 80822011 PowerPC mpc5200b_v21 PVR 80822011 PowerPC mpc5200b (alias for mpc5200b_v21) PowerPC mpc5200_v11 PVR 80822011 PowerPC mpc5200_v12 PVR 80822011 PowerPC mpc52xx (alias for mpc5200_v12) PowerPC mpc5200 (alias for mpc5200_v12) PowerPC g2legp1 PVR 80822011 PowerPC g2legp3 PVR 80822013 PowerPC mpc82xx (alias for g2legp3) PowerPC powerquicc-ii (alias for g2legp3) PowerPC mpc8247 (alias for g2legp3) PowerPC mpc8248 (alias for g2legp3) PowerPC mpc8270 (alias for g2legp3) PowerPC mpc8271 (alias for g2legp3) PowerPC mpc8272 (alias for g2legp3) PowerPC mpc8275 (alias for g2legp3) PowerPC mpc8280 (alias for g2legp3) PowerPC e200z5 PVR 81000000 PowerPC e200z6 PVR 81120000 PowerPC e200 (alias for e200z6) PowerPC g2ls PVR 90810010 PowerPC g2lels PVR a0822010
On Tue, Oct 05, 2021 at 06:44:23AM +0200, 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. Once something is deprecated, it remains in QEMU for a minimum of two release cycles, before being deleted. At any time in that deprecation period it can be returned to supported status, if someone provides a good enough justification to keep it. IOW, we can deprecate this now, and you still have plenty of time to investigate more. Regards, Daniel
On 05/10/2021 10.07, Thomas Huth wrote: > On 05/10/2021 10.05, Alexey Kardashevskiy wrote: [...] >> What is so special about taihu? > > taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I > suggested to deprecate now) I've now also played with the u-boot sources a little bit, and with some bit of tweaking, it's indeed possible to compile the old taihu board there. However, it does not really work with QEMU anymore, it immediately triggers an assert(): $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio ** ERROR:accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) Aborted (core dumped) Going back to QEMU v2.3.0, I can see at least a little bit of output, but it then also triggers an assert() during DRAM initialization: $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio Reset PowerPC core U-Boot 2014.10-rc2-00123-g461be2f96e-dirty (Oct 05 2021 - 10:02:56) CPU: AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128) I2C boot EEPROM disabled Internal PCI arbiter enabled 16 KiB I-Cache 16 KiB D-Cache Board: Taihu - AMCC PPC405EP Evaluation Board I2C: ready DRAM: qemu-system-ppc: memory.c:1693: memory_region_del_subregion: Assertion `subregion->container == mr' failed. Aborted (core dumped) Not sure if this ever worked in QEMU, maybe in the early 0.15 time, but that version of QEMU also does not compile easily anymore on modern systems. So I'm afraid, getting this into a workable shape again will take a lot of time. At least I'll stop my efforts here now. Thomas
On Tue, 5 Oct 2021, Thomas Huth wrote: > On 05/10/2021 10.07, Thomas Huth wrote: >> On 05/10/2021 10.05, Alexey Kardashevskiy wrote: > [...] >>> What is so special about taihu? >> >> taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I >> suggested to deprecate now) > > I've now also played with the u-boot sources a little bit, and with some bit > of tweaking, it's indeed possible to compile the old taihu board there. > However, it does not really work with QEMU anymore, it immediately triggers > an assert(): > > $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio > ** > ERROR:accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: > (qemu_mutex_iothread_locked()) > Aborted (core dumped) Maybe it's similar to this: 2025fc6766ab25501e0041c564c44bb0f7389774 The helper_load_dcr() and helper_store_dcr() in target/ppc/timebase_helper.c seem to lock/unlock the iothread but I'm not sure if that's necessary. Also not sure why this does not happen with 460ex but that maybe uses different code. > Going back to QEMU v2.3.0, I can see at least a little bit of output, but it > then also triggers an assert() during DRAM initialization: > > $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio > > Reset PowerPC core > > U-Boot 2014.10-rc2-00123-g461be2f96e-dirty (Oct 05 2021 - 10:02:56) > > CPU: AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128) > I2C boot EEPROM disabled > Internal PCI arbiter enabled > 16 KiB I-Cache 16 KiB D-Cache > Board: Taihu - AMCC PPC405EP Evaluation Board > I2C: ready > DRAM: qemu-system-ppc: memory.c:1693: memory_region_del_subregion: Assertion > `subregion->container == mr' failed. > Aborted (core dumped) > > Not sure if this ever worked in QEMU, maybe in the early 0.15 time, but that > version of QEMU also does not compile easily anymore on modern systems. So > I'm afraid, getting this into a workable shape again will take a lot of time. > At least I'll stop my efforts here now. Do you have this u-boot binary somewhere just for others who want to try it? Regards, BALATON Zoltan
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. Regards, BALATON Zoltan
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. Thomas
On 05/10/2021 14.17, BALATON Zoltan wrote: > On Tue, 5 Oct 2021, Thomas Huth wrote: >> On 05/10/2021 10.07, Thomas Huth wrote: >>> On 05/10/2021 10.05, Alexey Kardashevskiy wrote: >> [...] >>>> What is so special about taihu? >>> >>> taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I >>> suggested to deprecate now) >> >> I've now also played with the u-boot sources a little bit, and with some >> bit of tweaking, it's indeed possible to compile the old taihu board >> there. However, it does not really work with QEMU anymore, it immediately >> triggers an assert(): >> >> $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio >> ** >> ERROR:accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: >> (qemu_mutex_iothread_locked()) >> Aborted (core dumped) > > Maybe it's similar to this: 2025fc6766ab25501e0041c564c44bb0f7389774 The > helper_load_dcr() and helper_store_dcr() in target/ppc/timebase_helper.c > seem to lock/unlock the iothread but I'm not sure if that's necessary. Also > not sure why this does not happen with 460ex but that maybe uses different > code. It's rather the other way round, the locking is missing here instead. I can get the serial output with the current QEMU when I add the following patch (not sure whether that's the right spot, though): diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c index f5d012f860..bb57f1c9ed 100644 --- a/hw/ppc/ppc.c +++ b/hw/ppc/ppc.c @@ -336,6 +336,8 @@ void store_40x_dbcr0(CPUPPCState *env, uint32_t val) { PowerPCCPU *cpu = env_archcpu(env); + qemu_mutex_lock_iothread(); + switch ((val >> 28) & 0x3) { case 0x0: /* No action */ @@ -353,6 +355,8 @@ void store_40x_dbcr0(CPUPPCState *env, uint32_t val) ppc40x_system_reset(cpu); break; } + + qemu_mutex_unlock_iothread(); } /* PowerPC 40x internal IRQ controller */ >> Going back to QEMU v2.3.0, I can see at least a little bit of output, but >> it then also triggers an assert() during DRAM initialization: >> >> $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio >> >> Reset PowerPC core >> >> U-Boot 2014.10-rc2-00123-g461be2f96e-dirty (Oct 05 2021 - 10:02:56) >> >> CPU: AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128) >> I2C boot EEPROM disabled >> Internal PCI arbiter enabled >> 16 KiB I-Cache 16 KiB D-Cache >> Board: Taihu - AMCC PPC405EP Evaluation Board >> I2C: ready >> DRAM: qemu-system-ppc: memory.c:1693: memory_region_del_subregion: >> Assertion `subregion->container == mr' failed. >> Aborted (core dumped) >> >> Not sure if this ever worked in QEMU, maybe in the early 0.15 time, but >> that version of QEMU also does not compile easily anymore on modern >> systems. So I'm afraid, getting this into a workable shape again will take >> a lot of time. At least I'll stop my efforts here now. > > Do you have this u-boot binary somewhere just for others who want to try it? FWIW: http://people.redhat.com/~thuth/data/u-boot-taihu.bin Thomas
On 10/5/21 10:49, Daniel P. Berrangé wrote: > On Tue, Oct 05, 2021 at 06:44:23AM +0200, Christophe Leroy wrote: >> I will look at it, please allow me a few weeks though. > > Once something is deprecated, it remains in QEMU for a minimum of two > release cycles, before being deleted. At any time in that deprecation > period it can be returned to supported status, if someone provides a > good enough justification to keep it. My understanding is once being in deprecated state for 2 releases, it can be removed, but it doesn't have to be removed (assuming it is functional and nobody complains). Am I incorrect? I am raising this because the nanoMIPS support is in deprecated state since more than 2 releases, but it is still in-tree and I try to keep it functional. However, since no toolchain reached mainstream GCC/LLVM it is not easy to maintain. By keeping it in that state we give some time to other communities to have their toolchain upstreamed / merged. > IOW, we can deprecate this now, and you still have plenty of time to > investigate more. Yes, almost 8 months :)
On Tue, Oct 05, 2021 at 06:15:35PM +0200, Philippe Mathieu-Daudé wrote: > On 10/5/21 10:49, Daniel P. Berrangé wrote: > > On Tue, Oct 05, 2021 at 06:44:23AM +0200, Christophe Leroy wrote: > > >> I will look at it, please allow me a few weeks though. > > > > Once something is deprecated, it remains in QEMU for a minimum of two > > release cycles, before being deleted. At any time in that deprecation > > period it can be returned to supported status, if someone provides a > > good enough justification to keep it. > > My understanding is once being in deprecated state for 2 releases, it > can be removed, but it doesn't have to be removed (assuming it is > functional and nobody complains). Am I incorrect? It should be removed after 2 releases. Things live longer because people forget or are busy with other things, but ultimately anything in the deprecated list is liable to be deleted at any point after the 2 release minimum is up. If we change our minds about deleting something, then it should be un-deprecated. > I am raising this because the nanoMIPS support is in deprecated state > since more than 2 releases, but it is still in-tree and I try to keep > it functional. However, since no toolchain reached mainstream GCC/LLVM > it is not easy to maintain. By keeping it in that state we give some > time to other communities to have their toolchain upstreamed / merged. If you're trying to keep it functional and aren't going to remove it, then it shouldn't be marked deprecated. Regards, Daniel
On Tue, 5 Oct 2021, Thomas Huth wrote: > On 05/10/2021 14.17, BALATON Zoltan wrote: >> On Tue, 5 Oct 2021, Thomas Huth wrote: >>> On 05/10/2021 10.07, Thomas Huth wrote: >>>> On 05/10/2021 10.05, Alexey Kardashevskiy wrote: >>> [...] >>>>> What is so special about taihu? >>>> >>>> taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I >>>> suggested to deprecate now) >>> >>> I've now also played with the u-boot sources a little bit, and with some >>> bit of tweaking, it's indeed possible to compile the old taihu board >>> there. However, it does not really work with QEMU anymore, it immediately >>> triggers an assert(): >>> >>> $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio >>> ** >>> ERROR:accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: >>> (qemu_mutex_iothread_locked()) >>> Aborted (core dumped) >> >> Maybe it's similar to this: 2025fc6766ab25501e0041c564c44bb0f7389774 The >> helper_load_dcr() and helper_store_dcr() in target/ppc/timebase_helper.c >> seem to lock/unlock the iothread but I'm not sure if that's necessary. Also >> not sure why this does not happen with 460ex but that maybe uses different >> code. > > It's rather the other way round, the locking is missing here instead. I can > get the serial output with the current QEMU when I add the following patch > (not sure whether that's the right spot, though): > > diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c > index f5d012f860..bb57f1c9ed 100644 > --- a/hw/ppc/ppc.c > +++ b/hw/ppc/ppc.c > @@ -336,6 +336,8 @@ void store_40x_dbcr0(CPUPPCState *env, uint32_t val) > { > PowerPCCPU *cpu = env_archcpu(env); > > + qemu_mutex_lock_iothread(); > + > switch ((val >> 28) & 0x3) { > case 0x0: > /* No action */ > @@ -353,6 +355,8 @@ void store_40x_dbcr0(CPUPPCState *env, uint32_t val) > ppc40x_system_reset(cpu); > break; > } > + > + qemu_mutex_unlock_iothread(); > } > > /* PowerPC 40x internal IRQ controller */ > > >>> Going back to QEMU v2.3.0, I can see at least a little bit of output, but >>> it then also triggers an assert() during DRAM initialization: >>> >>> $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio >>> >>> Reset PowerPC core >>> >>> U-Boot 2014.10-rc2-00123-g461be2f96e-dirty (Oct 05 2021 - 10:02:56) >>> >>> CPU: AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128) >>> I2C boot EEPROM disabled >>> Internal PCI arbiter enabled >>> 16 KiB I-Cache 16 KiB D-Cache >>> Board: Taihu - AMCC PPC405EP Evaluation Board >>> I2C: ready >>> DRAM: qemu-system-ppc: memory.c:1693: memory_region_del_subregion: >>> Assertion `subregion->container == mr' failed. >>> Aborted (core dumped) The assert can be avoided with this patch: diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c index 980c48944f..3a4a094772 100644 --- a/hw/ppc/ppc4xx_devs.c +++ b/hw/ppc/ppc4xx_devs.c @@ -169,7 +170,8 @@ static target_ulong sdram_size (uint32_t bcr) static void sdram_set_bcr(ppc4xx_sdram_t *sdram, int i, uint32_t bcr, int enabled) { - if (sdram->bcr[i] & 0x00000001) { + if (sdram->bcr[i] & 0x00000001 && + memory_region_is_mapped(&sdram->containers[i])) { /* Unmap RAM */ #ifdef DEBUG_SDRAM printf("%s: unmap RAM area " TARGET_FMT_plx " " TARGET_FMT_lx "\n", @@ -220,8 +222,7 @@ static void sdram_unmap_bcr (ppc4xx_sdram_t *sdram) printf("%s: Unmap RAM area " TARGET_FMT_plx " " TARGET_FMT_lx "\n", __func__, sdram_base(sdram->bcr[i]), sdram_size(sdram->bcr[i])); #endif - memory_region_del_subregion(get_system_memory(), - &sdram->ram_memories[i]); + sdram_set_bcr(sdram, i, 0x00000000, 0); } } which then detects 128MiB RAM but leaves the controller disabled and thus RAM unmapped then it does not continue (not sure if because of disabled SDRAM controller or some other reason). I get this with #define DEBUG_SDRAM: Board: Taihu - AMCC PPC405EP Evaluation Board I2C: ready DRAM: dcr_write_sdram: enable SDRAM controller sdram_set_bcr: Map RAM area 0000000000000000 04000000 sdram_set_bcr: Map RAM area 0000000004000000 04000000 dcr_write_sdram: disable SDRAM controller sdram_unmap_bcr: Unmap RAM area 0000000000000000 04000000 sdram_set_bcr: unmap RAM area 0000000000000000 04000000 sdram_unmap_bcr: Unmap RAM area 0000000004000000 04000000 sdram_set_bcr: unmap RAM area 0000000004000000 04000000 dcr_write_sdram: enable SDRAM controller sdram_set_bcr: Map RAM area 0000000000000000 04000000 sdram_set_bcr: Map RAM area 0000000004000000 04000000 sdram_set_bcr: unmap RAM area 0000000004000000 04000000 dcr_write_sdram: disable SDRAM controller sdram_unmap_bcr: Unmap RAM area 0000000000000000 04000000 sdram_set_bcr: unmap RAM area 0000000000000000 04000000 sdram_unmap_bcr: Unmap RAM area 0000000000000000 00400000 128 MiB If this is simliar to the sam460ex u-boot then AFAIR that looks for SPD data from memory modules and sets up RAM according to those at this point (probably the same here as there's an i2c init before DRAM) then also runs some speed calibration routine that may need more registers emulated for the SDRAM controller. We have very similar code for the PPC440 based 460ex in ppc440_uc that I think I've copied from this and modified to work with the sam460ex u-boot. This could be cleaned up to share common code more but these may have slightly different registers and the bcr value is different too which is dependent on the supported memory sizes that are different between the two SoCs. Maybe these 405 boards in QEMU ran with modified firmware where the memory detection was patched out but it seems to detect the RAM so I wonder where it gets that from. Maybe by reading the SDRAM controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what it needs the SPD for, I forgot how this worked on sam460ex. Maybe for the speed calibration, so could be it detects ram by reading DCRs then tries to get SPD data and that's where it stops as i2c is not emulated on taihu. This could be confirmed by checking what it pokes with -d guest_errors that shows accesses to missing devices but don't know where 405 has the i2c controller and if it's the same as newer SoCs. If so that could be reused and an i2c bus could be added with the SPD data like in sam460ex to make u-boot happy or you could skip this in u-boot. Regards, BALATON Zoltan
On 05/10/2021 23.53, BALATON Zoltan wrote: [...] > Maybe these 405 boards in QEMU ran with modified firmware where the memory > detection was patched out I guess you're right - the code also expects a file called ppc405_rom.bin, and not u-boot.bin, so this board was likely used with a completely different firmware (which is not available anymore), not with u-boot... Thomas
On 05/10/2021 23.53, BALATON Zoltan wrote: [...] > Maybe these 405 boards in QEMU ran with modified firmware where the memory > detection was patched out but it seems to detect the RAM so I wonder where > it gets that from. Maybe by reading the SDRAM controller DCRs > ppc4xx_sdram_init() sets up. Then I'm not sure what it needs the SPD for, I > forgot how this worked on sam460ex. Maybe for the speed calibration, so > could be it detects ram by reading DCRs then tries to get SPD data and > that's where it stops as i2c is not emulated on taihu. This could be > confirmed by checking what it pokes with -d guest_errors that shows accesses > to missing devices but don't know where 405 has the i2c controller and if > it's the same as newer SoCs. If so that could be reused and an i2c bus could > be added with the SPD data like in sam460ex to make u-boot happy or you > could skip this in u-boot. FWIW, I've just tried the latter (skipping the sdram init in u-boot), and indeed, I can get to the u-boot prompt now. Binary can be found here: http://people.redhat.com/~thuth/data/u-boot-taihu-skip-sdram.bin Christophe, maybe that's already enough for you to boot a Linux kernel with the "taihu" board? (or do you need the ref405ep board instead?) I've also attached the patch with my modifications to u-boot. To build the u-boot firmware: git clone git://git.denx.de/u-boot.git cd u-boot git checkout 123b6cd7a4f75536734a7bff97db6eebce614bd1~1 patch -p1 -i .../u-boot-taihu.patch make taihu_defconfig CROSS_COMPILE=powerpc-... make CROSS_COMPILE=powerpc-... ... if the linker complains at the end, remove some features from the ".config" file, like CONFIG_CMD_NFS, and run make again. Thomas
On 06/10/2021 09.25, Thomas Huth wrote: > On 05/10/2021 23.53, BALATON Zoltan wrote: > [...] >> Maybe these 405 boards in QEMU ran with modified firmware where the memory >> detection was patched out but it seems to detect the RAM so I wonder where >> it gets that from. Maybe by reading the SDRAM controller DCRs >> ppc4xx_sdram_init() sets up. Then I'm not sure what it needs the SPD for, >> I forgot how this worked on sam460ex. Maybe for the speed calibration, so >> could be it detects ram by reading DCRs then tries to get SPD data and >> that's where it stops as i2c is not emulated on taihu. This could be >> confirmed by checking what it pokes with -d guest_errors that shows >> accesses to missing devices but don't know where 405 has the i2c >> controller and if it's the same as newer SoCs. If so that could be reused >> and an i2c bus could be added with the SPD data like in sam460ex to make >> u-boot happy or you could skip this in u-boot. > > FWIW, I've just tried the latter (skipping the sdram init in u-boot), and > indeed, I can get to the u-boot prompt now. [...]> I've also attached the patch with my modifications to u-boot. FYI, the changes can now be found on this branch here: https://gitlab.com/huth/u-boot/-/commits/taihu I also added a gitlab-CI file, so you can now download the u-boot.bin as an artifact from the corresponding pipeline, e.g.: https://gitlab.com/huth/u-boot/-/jobs/1667201028 Thomas
On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: > On 06/10/2021 09.25, Thomas Huth wrote: > > On 05/10/2021 23.53, BALATON Zoltan wrote: > > [...] > > > Maybe these 405 boards in QEMU ran with modified firmware where the > > > memory detection was patched out but it seems to detect the RAM so I > > > wonder where it gets that from. Maybe by reading the SDRAM > > > controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what > > > it needs the SPD for, I forgot how this worked on sam460ex. Maybe > > > for the speed calibration, so could be it detects ram by reading > > > DCRs then tries to get SPD data and that's where it stops as i2c is > > > not emulated on taihu. This could be confirmed by checking what it > > > pokes with -d guest_errors that shows accesses to missing devices > > > but don't know where 405 has the i2c controller and if it's the same > > > as newer SoCs. If so that could be reused and an i2c bus could be > > > added with the SPD data like in sam460ex to make u-boot happy or you > > > could skip this in u-boot. > > > > FWIW, I've just tried the latter (skipping the sdram init in u-boot), > > and indeed, I can get to the u-boot prompt now. > [...]> I've also attached the patch with my modifications to u-boot. > > FYI, the changes can now be found on this branch here: > > https://gitlab.com/huth/u-boot/-/commits/taihu > > I also added a gitlab-CI file, so you can now download the u-boot.bin as an > artifact from the corresponding pipeline, e.g.: > > https://gitlab.com/huth/u-boot/-/jobs/1667201028 Thanks. Are you going to send a v2 of your proposed deprecation patches? If you do can you please CC me explicitly. I only scan qemu-ppc once a week or so, and it goes into a different folder. If I'm CCed I'll notice and respond to it faster.
On 11/10/2021 11.20, David Gibson wrote: > On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >> On 06/10/2021 09.25, Thomas Huth wrote: >>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>> [...] >>>> Maybe these 405 boards in QEMU ran with modified firmware where the >>>> memory detection was patched out but it seems to detect the RAM so I >>>> wonder where it gets that from. Maybe by reading the SDRAM >>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what >>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe >>>> for the speed calibration, so could be it detects ram by reading >>>> DCRs then tries to get SPD data and that's where it stops as i2c is >>>> not emulated on taihu. This could be confirmed by checking what it >>>> pokes with -d guest_errors that shows accesses to missing devices >>>> but don't know where 405 has the i2c controller and if it's the same >>>> as newer SoCs. If so that could be reused and an i2c bus could be >>>> added with the SPD data like in sam460ex to make u-boot happy or you >>>> could skip this in u-boot. >>> >>> FWIW, I've just tried the latter (skipping the sdram init in u-boot), >>> and indeed, I can get to the u-boot prompt now. >> [...]> I've also attached the patch with my modifications to u-boot. >> >> FYI, the changes can now be found on this branch here: >> >> https://gitlab.com/huth/u-boot/-/commits/taihu >> >> I also added a gitlab-CI file, so you can now download the u-boot.bin as an >> artifact from the corresponding pipeline, e.g.: >> >> https://gitlab.com/huth/u-boot/-/jobs/1667201028 > > Thanks. > > Are you going to send a v2 of your proposed deprecation patches? No, since there was interest in keeping the 405 boards for testing the 405 code in the Linux kernel, and since there is now a way to do at least some very basic testing of these boards (with the u-boot firmware), I don't plan to respin the deprecation patch. I just sent a patch for adding the boards to our CI instead: https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html Thomas
Le 11/10/2021 à 15:24, Thomas Huth a écrit : > On 11/10/2021 11.20, David Gibson wrote: >> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>> On 06/10/2021 09.25, Thomas Huth wrote: >>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>> [...] >>>>> Maybe these 405 boards in QEMU ran with modified firmware where the >>>>> memory detection was patched out but it seems to detect the RAM so I >>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what >>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe >>>>> for the speed calibration, so could be it detects ram by reading >>>>> DCRs then tries to get SPD data and that's where it stops as i2c is >>>>> not emulated on taihu. This could be confirmed by checking what it >>>>> pokes with -d guest_errors that shows accesses to missing devices >>>>> but don't know where 405 has the i2c controller and if it's the same >>>>> as newer SoCs. If so that could be reused and an i2c bus could be >>>>> added with the SPD data like in sam460ex to make u-boot happy or you >>>>> could skip this in u-boot. >>>> >>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot), >>>> and indeed, I can get to the u-boot prompt now. >>> [...]> I've also attached the patch with my modifications to u-boot. >>> >>> FYI, the changes can now be found on this branch here: >>> >>> https://gitlab.com/huth/u-boot/-/commits/taihu >>> >>> I also added a gitlab-CI file, so you can now download the u-boot.bin >>> as an >>> artifact from the corresponding pipeline, e.g.: >>> >>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >> >> Thanks. >> >> Are you going to send a v2 of your proposed deprecation patches? > > No, since there was interest in keeping the 405 boards for testing the > 405 code in the Linux kernel, and since there is now a way to do at > least some very basic testing of these boards (with the u-boot > firmware), I don't plan to respin the deprecation patch. I just sent a > patch for adding the boards to our CI instead: > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html > I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and mainline, and I get: ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) Abandon (core dumped) I see in the mail history that you got that problem as well at some point. How did you fix it ? Thanks Christophe
On 19/10/2021 11.31, Christophe Leroy wrote: > > > Le 11/10/2021 à 15:24, Thomas Huth a écrit : >> On 11/10/2021 11.20, David Gibson wrote: >>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>>> On 06/10/2021 09.25, Thomas Huth wrote: >>>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>>> [...] >>>>>> Maybe these 405 boards in QEMU ran with modified firmware where the >>>>>> memory detection was patched out but it seems to detect the RAM so I >>>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what >>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe >>>>>> for the speed calibration, so could be it detects ram by reading >>>>>> DCRs then tries to get SPD data and that's where it stops as i2c is >>>>>> not emulated on taihu. This could be confirmed by checking what it >>>>>> pokes with -d guest_errors that shows accesses to missing devices >>>>>> but don't know where 405 has the i2c controller and if it's the same >>>>>> as newer SoCs. If so that could be reused and an i2c bus could be >>>>>> added with the SPD data like in sam460ex to make u-boot happy or you >>>>>> could skip this in u-boot. >>>>> >>>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot), >>>>> and indeed, I can get to the u-boot prompt now. >>>> [...]> I've also attached the patch with my modifications to u-boot. >>>> >>>> FYI, the changes can now be found on this branch here: >>>> >>>> https://gitlab.com/huth/u-boot/-/commits/taihu >>>> >>>> I also added a gitlab-CI file, so you can now download the u-boot.bin as an >>>> artifact from the corresponding pipeline, e.g.: >>>> >>>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >>> >>> Thanks. >>> >>> Are you going to send a v2 of your proposed deprecation patches? >> >> No, since there was interest in keeping the 405 boards for testing the 405 >> code in the Linux kernel, and since there is now a way to do at least some >> very basic testing of these boards (with the u-boot firmware), I don't >> plan to respin the deprecation patch. I just sent a patch for adding the >> boards to our CI instead: >> >> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html >> > > I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and > mainline, and I get: > > ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion > failed: (qemu_mutex_iothread_locked()) > Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: > assertion failed: (qemu_mutex_iothread_locked()) > Abandon (core dumped) > > I see in the mail history that you got that problem as well at some point. > How did you fix it ? You need this patch here to fix this issue: https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html ("hw/ppc: Fix iothread locking in the 405 code") Thomas
On Tue, 19 Oct 2021 11:31:03 +0200 Christophe Leroy <christophe.leroy@csgroup.eu> wrote: > > > Le 11/10/2021 à 15:24, Thomas Huth a écrit : > > On 11/10/2021 11.20, David Gibson wrote: > >> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: > >>> On 06/10/2021 09.25, Thomas Huth wrote: > >>>> On 05/10/2021 23.53, BALATON Zoltan wrote: > >>>> [...] > >>>>> Maybe these 405 boards in QEMU ran with modified firmware where the > >>>>> memory detection was patched out but it seems to detect the RAM so I > >>>>> wonder where it gets that from. Maybe by reading the SDRAM > >>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what > >>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe > >>>>> for the speed calibration, so could be it detects ram by reading > >>>>> DCRs then tries to get SPD data and that's where it stops as i2c is > >>>>> not emulated on taihu. This could be confirmed by checking what it > >>>>> pokes with -d guest_errors that shows accesses to missing devices > >>>>> but don't know where 405 has the i2c controller and if it's the same > >>>>> as newer SoCs. If so that could be reused and an i2c bus could be > >>>>> added with the SPD data like in sam460ex to make u-boot happy or you > >>>>> could skip this in u-boot. > >>>> > >>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot), > >>>> and indeed, I can get to the u-boot prompt now. > >>> [...]> I've also attached the patch with my modifications to u-boot. > >>> > >>> FYI, the changes can now be found on this branch here: > >>> > >>> https://gitlab.com/huth/u-boot/-/commits/taihu > >>> > >>> I also added a gitlab-CI file, so you can now download the u-boot.bin > >>> as an > >>> artifact from the corresponding pipeline, e.g.: > >>> > >>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 > >> > >> Thanks. > >> > >> Are you going to send a v2 of your proposed deprecation patches? > > > > No, since there was interest in keeping the 405 boards for testing the > > 405 code in the Linux kernel, and since there is now a way to do at > > least some very basic testing of these boards (with the u-boot > > firmware), I don't plan to respin the deprecation patch. I just sent a > > patch for adding the boards to our CI instead: > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html > > > > I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and > mainline, and I get: > > ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion > failed: (qemu_mutex_iothread_locked()) > Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: > assertion failed: (qemu_mutex_iothread_locked()) > Abandon (core dumped) > > I see in the mail history that you got that problem as well at some > point. How did you fix it ? > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html Not yet upstream but already in David's ppc-for-6.2 tree : https://gitlab.com/dgibson/qemu/-/commit/c29fca5c8173e9e647ebff07cb78b7c8135bd11a > Thanks > Christophe
Le 19/10/2021 à 11:39, Thomas Huth a écrit : > On 19/10/2021 11.31, Christophe Leroy wrote: >> >> >> Le 11/10/2021 à 15:24, Thomas Huth a écrit : >>> On 11/10/2021 11.20, David Gibson wrote: >>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>>>> On 06/10/2021 09.25, Thomas Huth wrote: >>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>>>> [...] >>>>>>> Maybe these 405 boards in QEMU ran with modified firmware where the >>>>>>> memory detection was patched out but it seems to detect the RAM so I >>>>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what >>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe >>>>>>> for the speed calibration, so could be it detects ram by reading >>>>>>> DCRs then tries to get SPD data and that's where it stops as i2c is >>>>>>> not emulated on taihu. This could be confirmed by checking what it >>>>>>> pokes with -d guest_errors that shows accesses to missing devices >>>>>>> but don't know where 405 has the i2c controller and if it's the same >>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be >>>>>>> added with the SPD data like in sam460ex to make u-boot happy or you >>>>>>> could skip this in u-boot. >>>>>> >>>>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot), >>>>>> and indeed, I can get to the u-boot prompt now. >>>>> [...]> I've also attached the patch with my modifications to u-boot. >>>>> >>>>> FYI, the changes can now be found on this branch here: >>>>> >>>>> https://gitlab.com/huth/u-boot/-/commits/taihu >>>>> >>>>> I also added a gitlab-CI file, so you can now download the >>>>> u-boot.bin as an >>>>> artifact from the corresponding pipeline, e.g.: >>>>> >>>>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >>>> >>>> Thanks. >>>> >>>> Are you going to send a v2 of your proposed deprecation patches? >>> >>> No, since there was interest in keeping the 405 boards for testing >>> the 405 code in the Linux kernel, and since there is now a way to do >>> at least some very basic testing of these boards (with the u-boot >>> firmware), I don't plan to respin the deprecation patch. I just sent >>> a patch for adding the boards to our CI instead: >>> >>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html >>> >> >> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 >> and mainline, and I get: >> >> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion >> failed: (qemu_mutex_iothread_locked()) >> Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >> assertion failed: (qemu_mutex_iothread_locked()) >> Abandon (core dumped) >> >> I see in the mail history that you got that problem as well at some >> point. How did you fix it ? > > You need this patch here to fix this issue: > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html > ("hw/ppc: Fix iothread locking in the 405 code") > Thank you. Is there anything special to do then in order to boot a Linux kernel ? I build the uImage for ppc40x_defconfig I use the following command, but it does nothing, it stays in uboot prompt as when I don't get a kernel argument ~/qemu/build/qemu-system-ppc -M taihu -bios ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel arch/powerpc/boot/uImage Thanks Christophe
On Tue, 19 Oct 2021, Christophe Leroy wrote: > Le 19/10/2021 à 11:39, Thomas Huth a écrit : >> On 19/10/2021 11.31, Christophe Leroy wrote: >>> Le 11/10/2021 à 15:24, Thomas Huth a écrit : >>>> On 11/10/2021 11.20, David Gibson wrote: >>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>>>>> On 06/10/2021 09.25, Thomas Huth wrote: >>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>>>>> [...] >>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware where the >>>>>>>> memory detection was patched out but it seems to detect the RAM so I >>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what >>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe >>>>>>>> for the speed calibration, so could be it detects ram by reading >>>>>>>> DCRs then tries to get SPD data and that's where it stops as i2c is >>>>>>>> not emulated on taihu. This could be confirmed by checking what it >>>>>>>> pokes with -d guest_errors that shows accesses to missing devices >>>>>>>> but don't know where 405 has the i2c controller and if it's the same >>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be >>>>>>>> added with the SPD data like in sam460ex to make u-boot happy or you >>>>>>>> could skip this in u-boot. >>>>>>> >>>>>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot), >>>>>>> and indeed, I can get to the u-boot prompt now. >>>>>> [...]> I've also attached the patch with my modifications to u-boot. >>>>>> >>>>>> FYI, the changes can now be found on this branch here: >>>>>> >>>>>> https://gitlab.com/huth/u-boot/-/commits/taihu >>>>>> >>>>>> I also added a gitlab-CI file, so you can now download the u-boot.bin >>>>>> as an >>>>>> artifact from the corresponding pipeline, e.g.: >>>>>> >>>>>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >>>>> >>>>> Thanks. >>>>> >>>>> Are you going to send a v2 of your proposed deprecation patches? >>>> >>>> No, since there was interest in keeping the 405 boards for testing the >>>> 405 code in the Linux kernel, and since there is now a way to do at least >>>> some very basic testing of these boards (with the u-boot firmware), I >>>> don't plan to respin the deprecation patch. I just sent a patch for >>>> adding the boards to our CI instead: >>>> >>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html >>>> >>> >>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and >>> mainline, and I get: >>> >>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion >>> failed: (qemu_mutex_iothread_locked()) >>> Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>> assertion failed: (qemu_mutex_iothread_locked()) >>> Abandon (core dumped) >>> >>> I see in the mail history that you got that problem as well at some point. >>> How did you fix it ? >> >> You need this patch here to fix this issue: >> >> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html >> ("hw/ppc: Fix iothread locking in the 405 code") >> > > Thank you. > > Is there anything special to do then in order to boot a Linux kernel ? > > I build the uImage for ppc40x_defconfig > > I use the following command, but it does nothing, it stays in uboot prompt as > when I don't get a kernel argument > > ~/qemu/build/qemu-system-ppc -M taihu -bios > ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel > arch/powerpc/boot/uImage I'm not sure using -bios and -kernel together makes sense, it probably starts u-boot in this case and you have to load and start the kernel from u-boot as you'd notmally do on a real machine. Alternatively you could use -kernel instead of -bios which then loads a kernel and starts it directly but not sure if it needs a firmware to work. Ot I could be completely wrong as I don't know this machine and haven't tried it. Regards, BALATON Zoltan
On 19/10/2021 12.07, BALATON Zoltan wrote: > On Tue, 19 Oct 2021, Christophe Leroy wrote: >> Le 19/10/2021 à 11:39, Thomas Huth a écrit : >>> On 19/10/2021 11.31, Christophe Leroy wrote: >>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit : >>>>> On 11/10/2021 11.20, David Gibson wrote: >>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>>>>>> On 06/10/2021 09.25, Thomas Huth wrote: >>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>>>>>> [...] >>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware where the >>>>>>>>> memory detection was patched out but it seems to detect the RAM so I >>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what >>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe >>>>>>>>> for the speed calibration, so could be it detects ram by reading >>>>>>>>> DCRs then tries to get SPD data and that's where it stops as i2c is >>>>>>>>> not emulated on taihu. This could be confirmed by checking what it >>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices >>>>>>>>> but don't know where 405 has the i2c controller and if it's the same >>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be >>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy or you >>>>>>>>> could skip this in u-boot. >>>>>>>> >>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot), >>>>>>>> and indeed, I can get to the u-boot prompt now. >>>>>>> [...]> I've also attached the patch with my modifications to u-boot. >>>>>>> >>>>>>> FYI, the changes can now be found on this branch here: >>>>>>> >>>>>>> https://gitlab.com/huth/u-boot/-/commits/taihu >>>>>>> >>>>>>> I also added a gitlab-CI file, so you can now download the u-boot.bin >>>>>>> as an >>>>>>> artifact from the corresponding pipeline, e.g.: >>>>>>> >>>>>>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Are you going to send a v2 of your proposed deprecation patches? >>>>> >>>>> No, since there was interest in keeping the 405 boards for testing the >>>>> 405 code in the Linux kernel, and since there is now a way to do at >>>>> least some very basic testing of these boards (with the u-boot >>>>> firmware), I don't plan to respin the deprecation patch. I just sent a >>>>> patch for adding the boards to our CI instead: >>>>> >>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html >>>>> >>>> >>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and >>>> mainline, and I get: >>>> >>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion >>>> failed: (qemu_mutex_iothread_locked()) >>>> Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>> assertion failed: (qemu_mutex_iothread_locked()) >>>> Abandon (core dumped) >>>> >>>> I see in the mail history that you got that problem as well at some >>>> point. How did you fix it ? >>> >>> You need this patch here to fix this issue: >>> >>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html >>> ("hw/ppc: Fix iothread locking in the 405 code") >>> >> >> Thank you. >> >> Is there anything special to do then in order to boot a Linux kernel ? >> >> I build the uImage for ppc40x_defconfig >> >> I use the following command, but it does nothing, it stays in uboot prompt >> as when I don't get a kernel argument >> >> ~/qemu/build/qemu-system-ppc -M taihu -bios >> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel >> arch/powerpc/boot/uImage > > I'm not sure using -bios and -kernel together makes sense, it probably > starts u-boot in this case and you have to load and start the kernel from > u-boot as you'd notmally do on a real machine. Alternatively you could use > -kernel instead of -bios which then loads a kernel and starts it directly > but not sure if it needs a firmware to work. > > Ot I could be completely wrong as I don't know this machine and haven't > tried it. Actually, these 405 machines are quite weird. They refuse to boot without bios image, so you currently need the firmware image for sure. OTOH, when you look at the ref405ep_init() function, it seems that at least the ref405ep machine was once supposed to start a kernel directly: env->nip = KERNEL_LOAD_ADDR; ... however, this does not seem to work anymore, the initial NIP is always reset to the firmware entry when the board resets. Not sure if/how this ever used worked ... Thomas
Le 19/10/2021 à 13:11, Thomas Huth a écrit : > On 19/10/2021 12.07, BALATON Zoltan wrote: >> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>> Le 19/10/2021 à 11:39, Thomas Huth a écrit : >>>> On 19/10/2021 11.31, Christophe Leroy wrote: >>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit : >>>>>> On 11/10/2021 11.20, David Gibson wrote: >>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote: >>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>>>>>>> [...] >>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware >>>>>>>>>> where the >>>>>>>>>> memory detection was patched out but it seems to detect the >>>>>>>>>> RAM so I >>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure >>>>>>>>>> what >>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe >>>>>>>>>> for the speed calibration, so could be it detects ram by reading >>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as >>>>>>>>>> i2c is >>>>>>>>>> not emulated on taihu. This could be confirmed by checking >>>>>>>>>> what it >>>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices >>>>>>>>>> but don't know where 405 has the i2c controller and if it's >>>>>>>>>> the same >>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be >>>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy >>>>>>>>>> or you >>>>>>>>>> could skip this in u-boot. >>>>>>>>> >>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in >>>>>>>>> u-boot), >>>>>>>>> and indeed, I can get to the u-boot prompt now. >>>>>>>> [...]> I've also attached the patch with my modifications to >>>>>>>> u-boot. >>>>>>>> >>>>>>>> FYI, the changes can now be found on this branch here: >>>>>>>> >>>>>>>> https://gitlab.com/huth/u-boot/-/commits/taihu >>>>>>>> >>>>>>>> I also added a gitlab-CI file, so you can now download the >>>>>>>> u-boot.bin as an >>>>>>>> artifact from the corresponding pipeline, e.g.: >>>>>>>> >>>>>>>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Are you going to send a v2 of your proposed deprecation patches? >>>>>> >>>>>> No, since there was interest in keeping the 405 boards for testing >>>>>> the 405 code in the Linux kernel, and since there is now a way to >>>>>> do at least some very basic testing of these boards (with the >>>>>> u-boot firmware), I don't plan to respin the deprecation patch. I >>>>>> just sent a patch for adding the boards to our CI instead: >>>>>> >>>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html >>>>>> >>>>> >>>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 >>>>> and mainline, and I get: >>>>> >>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>> Bail out! >>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>> Abandon (core dumped) >>>>> >>>>> I see in the mail history that you got that problem as well at some >>>>> point. How did you fix it ? >>>> >>>> You need this patch here to fix this issue: >>>> >>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html >>>> ("hw/ppc: Fix iothread locking in the 405 code") >>>> >>> >>> Thank you. >>> >>> Is there anything special to do then in order to boot a Linux kernel ? >>> >>> I build the uImage for ppc40x_defconfig >>> >>> I use the following command, but it does nothing, it stays in uboot >>> prompt as when I don't get a kernel argument >>> >>> ~/qemu/build/qemu-system-ppc -M taihu -bios >>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel >>> arch/powerpc/boot/uImage >> >> I'm not sure using -bios and -kernel together makes sense, it probably >> starts u-boot in this case and you have to load and start the kernel >> from u-boot as you'd notmally do on a real machine. Alternatively you >> could use -kernel instead of -bios which then loads a kernel and >> starts it directly but not sure if it needs a firmware to work. >> >> Ot I could be completely wrong as I don't know this machine and >> haven't tried it. > > Actually, these 405 machines are quite weird. They refuse to boot > without bios image, so you currently need the firmware image for sure. > > OTOH, when you look at the ref405ep_init() function, it seems that at > least the ref405ep machine was once supposed to start a kernel directly: > > env->nip = KERNEL_LOAD_ADDR; > > ... however, this does not seem to work anymore, the initial NIP is > always reset to the firmware entry when the board resets. Not sure > if/how this ever used worked ... > On the e500 we use both -bios and -kernel: qemu-system-ppc64 -nographic -M ppce500 -cpu e5500 -m 1G -bios u-boot-e500 -kernel ./arch/powerpc/boot/uImage -initrd ./qemu/rootfs.cpio.gz -append noreboot -s Uboot for e500 has the following environment: => printenv bootcmd=test -n "$qemu_kernel_addr" && bootm $qemu_kernel_addr - $fdt_addr_r fdt_addr_r=e8000000 qemu_kernel_addr=2000000 stderr=serial stdin=serial stdout=serial Environment size: 164/8188 bytes I think I need to findout where QEMU loads the kernel when using TAIHU machine. Christophe
On Tue, 19 Oct 2021, Christophe Leroy wrote: > Le 19/10/2021 à 13:11, Thomas Huth a écrit : >> On 19/10/2021 12.07, BALATON Zoltan wrote: >>> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit : >>>>> On 19/10/2021 11.31, Christophe Leroy wrote: >>>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit : >>>>>>> On 11/10/2021 11.20, David Gibson wrote: >>>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote: >>>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>>>>>>>> [...] >>>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware where >>>>>>>>>>> the >>>>>>>>>>> memory detection was patched out but it seems to detect the RAM so >>>>>>>>>>> I >>>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure >>>>>>>>>>> what >>>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe >>>>>>>>>>> for the speed calibration, so could be it detects ram by reading >>>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as i2c >>>>>>>>>>> is >>>>>>>>>>> not emulated on taihu. This could be confirmed by checking what it >>>>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices >>>>>>>>>>> but don't know where 405 has the i2c controller and if it's the >>>>>>>>>>> same >>>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be >>>>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy or >>>>>>>>>>> you >>>>>>>>>>> could skip this in u-boot. >>>>>>>>>> >>>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in >>>>>>>>>> u-boot), >>>>>>>>>> and indeed, I can get to the u-boot prompt now. >>>>>>>>> [...]> I've also attached the patch with my modifications to u-boot. >>>>>>>>> >>>>>>>>> FYI, the changes can now be found on this branch here: >>>>>>>>> >>>>>>>>> https://gitlab.com/huth/u-boot/-/commits/taihu >>>>>>>>> >>>>>>>>> I also added a gitlab-CI file, so you can now download the >>>>>>>>> u-boot.bin as an >>>>>>>>> artifact from the corresponding pipeline, e.g.: >>>>>>>>> >>>>>>>>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Are you going to send a v2 of your proposed deprecation patches? >>>>>>> >>>>>>> No, since there was interest in keeping the 405 boards for testing the >>>>>>> 405 code in the Linux kernel, and since there is now a way to do at >>>>>>> least some very basic testing of these boards (with the u-boot >>>>>>> firmware), I don't plan to respin the deprecation patch. I just sent a >>>>>>> patch for adding the boards to our CI instead: >>>>>>> >>>>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html >>>>>>> >>>>>> >>>>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and >>>>>> mainline, and I get: >>>>>> >>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion >>>>>> failed: (qemu_mutex_iothread_locked()) >>>>>> Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>>> Abandon (core dumped) >>>>>> >>>>>> I see in the mail history that you got that problem as well at some >>>>>> point. How did you fix it ? >>>>> >>>>> You need this patch here to fix this issue: >>>>> >>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html >>>>> ("hw/ppc: Fix iothread locking in the 405 code") >>>>> >>>> >>>> Thank you. >>>> >>>> Is there anything special to do then in order to boot a Linux kernel ? >>>> >>>> I build the uImage for ppc40x_defconfig >>>> >>>> I use the following command, but it does nothing, it stays in uboot >>>> prompt as when I don't get a kernel argument >>>> >>>> ~/qemu/build/qemu-system-ppc -M taihu -bios >>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel >>>> arch/powerpc/boot/uImage >>> >>> I'm not sure using -bios and -kernel together makes sense, it probably >>> starts u-boot in this case and you have to load and start the kernel from >>> u-boot as you'd notmally do on a real machine. Alternatively you could use >>> -kernel instead of -bios which then loads a kernel and starts it directly >>> but not sure if it needs a firmware to work. >>> >>> Ot I could be completely wrong as I don't know this machine and haven't >>> tried it. >> >> Actually, these 405 machines are quite weird. They refuse to boot without >> bios image, so you currently need the firmware image for sure. >> >> OTOH, when you look at the ref405ep_init() function, it seems that at least >> the ref405ep machine was once supposed to start a kernel directly: >> >> env->nip = KERNEL_LOAD_ADDR; >> >> ... however, this does not seem to work anymore, the initial NIP is always >> reset to the firmware entry when the board resets. Not sure if/how this >> ever used worked ... >> > > On the e500 we use both -bios and -kernel: > > qemu-system-ppc64 -nographic -M ppce500 -cpu e5500 -m 1G -bios > u-boot-e500 -kernel ./arch/powerpc/boot/uImage -initrd ./qemu/rootfs.cpio.gz > -append noreboot -s > > > Uboot for e500 has the following environment: > > => printenv > bootcmd=test -n "$qemu_kernel_addr" && bootm $qemu_kernel_addr - > $fdt_addr_r > fdt_addr_r=e8000000 > qemu_kernel_addr=2000000 > stderr=serial > stdin=serial > stdout=serial > > Environment size: 164/8188 bytes The -bios and -kernel options are handled by the machine code so these work differently on every machine depending on what they decide to do for these. > I think I need to findout where QEMU loads the kernel when using TAIHU > machine. Look in qemu/hw/ppc/ppc405_boards.c it has #define KERNEL_LOAD_ADDR 0x00000000 but it does not seem to do anything with a kernel other than loading it. I don't see anything that would start the kernel. I think this board is probably unfinished, if you want to use it you may need to implement some stuff in it. Also try using -d unimp,guest_errors options to see errors when something goes wrong otherwise you may not get much feedback. Regard, BALATON Zoltan
Le 19/10/2021 à 14:38, BALATON Zoltan a écrit : > On Tue, 19 Oct 2021, Christophe Leroy wrote: >> Le 19/10/2021 à 13:11, Thomas Huth a écrit : >>> On 19/10/2021 12.07, BALATON Zoltan wrote: >>>> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit : >>>>>> On 19/10/2021 11.31, Christophe Leroy wrote: >>>>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit : >>>>>>>> On 11/10/2021 11.20, David Gibson wrote: >>>>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>>>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote: >>>>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>>>>>>>>> [...] >>>>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware >>>>>>>>>>>> where the >>>>>>>>>>>> memory detection was patched out but it seems to detect the >>>>>>>>>>>> RAM so I >>>>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not >>>>>>>>>>>> sure what >>>>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. >>>>>>>>>>>> Maybe >>>>>>>>>>>> for the speed calibration, so could be it detects ram by >>>>>>>>>>>> reading >>>>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as >>>>>>>>>>>> i2c is >>>>>>>>>>>> not emulated on taihu. This could be confirmed by checking >>>>>>>>>>>> what it >>>>>>>>>>>> pokes with -d guest_errors that shows accesses to missing >>>>>>>>>>>> devices >>>>>>>>>>>> but don't know where 405 has the i2c controller and if it's >>>>>>>>>>>> the same >>>>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus >>>>>>>>>>>> could be >>>>>>>>>>>> added with the SPD data like in sam460ex to make u-boot >>>>>>>>>>>> happy or you >>>>>>>>>>>> could skip this in u-boot. >>>>>>>>>>> >>>>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in >>>>>>>>>>> u-boot), >>>>>>>>>>> and indeed, I can get to the u-boot prompt now. >>>>>>>>>> [...]> I've also attached the patch with my modifications to >>>>>>>>>> u-boot. >>>>>>>>>> >>>>>>>>>> FYI, the changes can now be found on this branch here: >>>>>>>>>> >>>>>>>>>> https://gitlab.com/huth/u-boot/-/commits/taihu >>>>>>>>>> >>>>>>>>>> I also added a gitlab-CI file, so you can now download the >>>>>>>>>> u-boot.bin as an >>>>>>>>>> artifact from the corresponding pipeline, e.g.: >>>>>>>>>> >>>>>>>>>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> Are you going to send a v2 of your proposed deprecation patches? >>>>>>>> >>>>>>>> No, since there was interest in keeping the 405 boards for >>>>>>>> testing the 405 code in the Linux kernel, and since there is now >>>>>>>> a way to do at least some very basic testing of these boards >>>>>>>> (with the u-boot firmware), I don't plan to respin the >>>>>>>> deprecation patch. I just sent a patch for adding the boards to >>>>>>>> our CI instead: >>>>>>>> >>>>>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I have downloaded your u-boot.bin and tried it with both QEMU >>>>>>> 5.2.0 and mainline, and I get: >>>>>>> >>>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>>>> Bail out! >>>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>>>> Abandon (core dumped) >>>>>>> >>>>>>> I see in the mail history that you got that problem as well at >>>>>>> some point. How did you fix it ? >>>>>> >>>>>> You need this patch here to fix this issue: >>>>>> >>>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html >>>>>> ("hw/ppc: Fix iothread locking in the 405 code") >>>>>> >>>>> >>>>> Thank you. >>>>> >>>>> Is there anything special to do then in order to boot a Linux kernel ? >>>>> >>>>> I build the uImage for ppc40x_defconfig >>>>> >>>>> I use the following command, but it does nothing, it stays in uboot >>>>> prompt as when I don't get a kernel argument >>>>> >>>>> ~/qemu/build/qemu-system-ppc -M taihu -bios >>>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel >>>>> arch/powerpc/boot/uImage >>>> >>>> I'm not sure using -bios and -kernel together makes sense, it >>>> probably starts u-boot in this case and you have to load and start >>>> the kernel from u-boot as you'd notmally do on a real machine. >>>> Alternatively you could use -kernel instead of -bios which then >>>> loads a kernel and starts it directly but not sure if it needs a >>>> firmware to work. >>>> >>>> Ot I could be completely wrong as I don't know this machine and >>>> haven't tried it. >>> >>> Actually, these 405 machines are quite weird. They refuse to boot >>> without bios image, so you currently need the firmware image for sure. >>> >>> OTOH, when you look at the ref405ep_init() function, it seems that at >>> least the ref405ep machine was once supposed to start a kernel directly: >>> >>> env->nip = KERNEL_LOAD_ADDR; >>> >>> ... however, this does not seem to work anymore, the initial NIP is >>> always reset to the firmware entry when the board resets. Not sure >>> if/how this ever used worked ... >>> >> >> On the e500 we use both -bios and -kernel: >> >> qemu-system-ppc64 -nographic -M ppce500 -cpu e5500 -m 1G -bios >> u-boot-e500 -kernel ./arch/powerpc/boot/uImage -initrd >> ./qemu/rootfs.cpio.gz -append noreboot -s >> >> >> Uboot for e500 has the following environment: >> >> => printenv >> bootcmd=test -n "$qemu_kernel_addr" && bootm $qemu_kernel_addr - >> $fdt_addr_r >> fdt_addr_r=e8000000 >> qemu_kernel_addr=2000000 >> stderr=serial >> stdin=serial >> stdout=serial >> >> Environment size: 164/8188 bytes > > The -bios and -kernel options are handled by the machine code so these > work differently on every machine depending on what they decide to do > for these. > >> I think I need to findout where QEMU loads the kernel when using TAIHU >> machine. > > Look in qemu/hw/ppc/ppc405_boards.c it has > #define KERNEL_LOAD_ADDR 0x00000000 > but it does not seem to do anything with a kernel other than loading it. > I don't see anything that would start the kernel. I think this board is > probably unfinished, if you want to use it you may need to implement > some stuff in it. Also try using -d unimp,guest_errors options to see > errors when something goes wrong otherwise you may not get much feedback. > There is something: => bootm 0 Wrong Image Format for bootm command ERROR: can't get kernel image! => md 0 00000000: 00000000 b497aae1 616e9207 003227a4 '..V....an...2'. 00000010: 00000000 00000000 ee36255f 05070201 .........6%_.... 00000020: 4c696e75 782d352e 31352e30 2d726335 Linux-5.15.0-rc5 00000030: 2d303232 32342d67 61336330 30376164 -02224-ga3c007ad 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7 ...........\.p.. => mw.l 0 0x27051956 => bootm 0 ## Booting kernel from Legacy Image at 00000000 ... Image Name: Linux-5.15.0-rc5-02224-ga3c007ad Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 3286948 Bytes = 3.1 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... Bad Data CRC ERROR: can't get kernel image! So we have something but it seems it gets overwritten by stuff. Anyway loading a uImage at 0 is just bad because it is a gzipped image that should get gunzipped at address 0. Or should we just copy the raw kernel at 0 and jump to the entry point ? But then we also need a device tree somewhere. Christophe
Le 19/10/2021 à 15:44, Christophe Leroy a écrit : > > > Le 19/10/2021 à 14:38, BALATON Zoltan a écrit : >> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>> Le 19/10/2021 à 13:11, Thomas Huth a écrit : >>>> On 19/10/2021 12.07, BALATON Zoltan wrote: >>>>> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>>>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit : >>>>>>> On 19/10/2021 11.31, Christophe Leroy wrote: >>>>>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit : >>>>>>>>> On 11/10/2021 11.20, David Gibson wrote: >>>>>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>>>>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote: >>>>>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>>>>>>>>>> [...] >>>>>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware >>>>>>>>>>>>> where the >>>>>>>>>>>>> memory detection was patched out but it seems to detect the >>>>>>>>>>>>> RAM so I >>>>>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not >>>>>>>>>>>>> sure what >>>>>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. >>>>>>>>>>>>> Maybe >>>>>>>>>>>>> for the speed calibration, so could be it detects ram by >>>>>>>>>>>>> reading >>>>>>>>>>>>> DCRs then tries to get SPD data and that's where it stops >>>>>>>>>>>>> as i2c is >>>>>>>>>>>>> not emulated on taihu. This could be confirmed by checking >>>>>>>>>>>>> what it >>>>>>>>>>>>> pokes with -d guest_errors that shows accesses to missing >>>>>>>>>>>>> devices >>>>>>>>>>>>> but don't know where 405 has the i2c controller and if it's >>>>>>>>>>>>> the same >>>>>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus >>>>>>>>>>>>> could be >>>>>>>>>>>>> added with the SPD data like in sam460ex to make u-boot >>>>>>>>>>>>> happy or you >>>>>>>>>>>>> could skip this in u-boot. >>>>>>>>>>>> >>>>>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in >>>>>>>>>>>> u-boot), >>>>>>>>>>>> and indeed, I can get to the u-boot prompt now. >>>>>>>>>>> [...]> I've also attached the patch with my modifications to >>>>>>>>>>> u-boot. >>>>>>>>>>> >>>>>>>>>>> FYI, the changes can now be found on this branch here: >>>>>>>>>>> >>>>>>>>>>> https://gitlab.com/huth/u-boot/-/commits/taihu >>>>>>>>>>> >>>>>>>>>>> I also added a gitlab-CI file, so you can now download the >>>>>>>>>>> u-boot.bin as an >>>>>>>>>>> artifact from the corresponding pipeline, e.g.: >>>>>>>>>>> >>>>>>>>>>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> Are you going to send a v2 of your proposed deprecation patches? >>>>>>>>> >>>>>>>>> No, since there was interest in keeping the 405 boards for >>>>>>>>> testing the 405 code in the Linux kernel, and since there is >>>>>>>>> now a way to do at least some very basic testing of these >>>>>>>>> boards (with the u-boot firmware), I don't plan to respin the >>>>>>>>> deprecation patch. I just sent a patch for adding the boards to >>>>>>>>> our CI instead: >>>>>>>>> >>>>>>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I have downloaded your u-boot.bin and tried it with both QEMU >>>>>>>> 5.2.0 and mainline, and I get: >>>>>>>> >>>>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>>>>> Bail out! >>>>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>>>>> Abandon (core dumped) >>>>>>>> >>>>>>>> I see in the mail history that you got that problem as well at >>>>>>>> some point. How did you fix it ? >>>>>>> >>>>>>> You need this patch here to fix this issue: >>>>>>> >>>>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html >>>>>>> >>>>>>> ("hw/ppc: Fix iothread locking in the 405 code") >>>>>>> >>>>>> >>>>>> Thank you. >>>>>> >>>>>> Is there anything special to do then in order to boot a Linux >>>>>> kernel ? >>>>>> >>>>>> I build the uImage for ppc40x_defconfig >>>>>> >>>>>> I use the following command, but it does nothing, it stays in >>>>>> uboot prompt as when I don't get a kernel argument >>>>>> >>>>>> ~/qemu/build/qemu-system-ppc -M taihu -bios >>>>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio >>>>>> -kernel arch/powerpc/boot/uImage >>>>> >>>>> I'm not sure using -bios and -kernel together makes sense, it >>>>> probably starts u-boot in this case and you have to load and start >>>>> the kernel from u-boot as you'd notmally do on a real machine. >>>>> Alternatively you could use -kernel instead of -bios which then >>>>> loads a kernel and starts it directly but not sure if it needs a >>>>> firmware to work. >>>>> >>>>> Ot I could be completely wrong as I don't know this machine and >>>>> haven't tried it. >>>> >>>> Actually, these 405 machines are quite weird. They refuse to boot >>>> without bios image, so you currently need the firmware image for sure. >>>> >>>> OTOH, when you look at the ref405ep_init() function, it seems that >>>> at least the ref405ep machine was once supposed to start a kernel >>>> directly: >>>> >>>> env->nip = KERNEL_LOAD_ADDR; >>>> >>>> ... however, this does not seem to work anymore, the initial NIP is >>>> always reset to the firmware entry when the board resets. Not sure >>>> if/how this ever used worked ... >>>> >>> >>> On the e500 we use both -bios and -kernel: >>> >>> qemu-system-ppc64 -nographic -M ppce500 -cpu e5500 -m 1G -bios >>> u-boot-e500 -kernel ./arch/powerpc/boot/uImage -initrd >>> ./qemu/rootfs.cpio.gz -append noreboot -s >>> >>> >>> Uboot for e500 has the following environment: >>> >>> => printenv >>> bootcmd=test -n "$qemu_kernel_addr" && bootm $qemu_kernel_addr - >>> $fdt_addr_r >>> fdt_addr_r=e8000000 >>> qemu_kernel_addr=2000000 >>> stderr=serial >>> stdin=serial >>> stdout=serial >>> >>> Environment size: 164/8188 bytes >> >> The -bios and -kernel options are handled by the machine code so these >> work differently on every machine depending on what they decide to do >> for these. >> >>> I think I need to findout where QEMU loads the kernel when using >>> TAIHU machine. >> >> Look in qemu/hw/ppc/ppc405_boards.c it has >> #define KERNEL_LOAD_ADDR 0x00000000 >> but it does not seem to do anything with a kernel other than loading >> it. I don't see anything that would start the kernel. I think this >> board is probably unfinished, if you want to use it you may need to >> implement some stuff in it. Also try using -d unimp,guest_errors >> options to see errors when something goes wrong otherwise you may not >> get much feedback. >> > > There is something: > > => bootm 0 > Wrong Image Format for bootm command > ERROR: can't get kernel image! > > => md 0 > 00000000: 00000000 b497aae1 616e9207 003227a4 '..V....an...2'. > 00000010: 00000000 00000000 ee36255f 05070201 .........6%_.... > 00000020: 4c696e75 782d352e 31352e30 2d726335 Linux-5.15.0-rc5 > 00000030: 2d303232 32342d67 61336330 30376164 -02224-ga3c007ad > 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7 ...........\.p.. > > => mw.l 0 0x27051956 > > => bootm 0 > ## Booting kernel from Legacy Image at 00000000 ... > Image Name: Linux-5.15.0-rc5-02224-ga3c007ad > Image Type: PowerPC Linux Kernel Image (gzip compressed) > Data Size: 3286948 Bytes = 3.1 MiB > Load Address: 00000000 > Entry Point: 00000000 > Verifying Checksum ... Bad Data CRC > ERROR: can't get kernel image! > > > So we have something but it seems it gets overwritten by stuff. > > Anyway loading a uImage at 0 is just bad because it is a gzipped image > that should get gunzipped at address 0. > > Or should we just copy the raw kernel at 0 and jump to the entry point ? > But then we also need a device tree somewhere. > If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that address, and it seems it properly decompress the kernel: => bootm 0x1000000 ## Booting kernel from Legacy Image at 01000000 ... Image Name: Linux-5.15.0-rc5-02224-ga3c007ad Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 3296789 Bytes = 3.1 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK And it initialises the MMU properly. Then it gets stuck because there is no devicetree. (gdb) bt #0 0xc00094cc in udelay () #1 0xc0025d34 in panic () #2 0xc06415a0 in early_init_devtree () #3 0xc0641da8 in machine_init () #4 0xc0002200 in start_here () Christophe
On Tue, 19 Oct 2021, Christophe Leroy wrote: > Le 19/10/2021 à 15:44, Christophe Leroy a écrit : >> There is something: >> >> => bootm 0 >> Wrong Image Format for bootm command >> ERROR: can't get kernel image! >> >> => md 0 >> 00000000: 00000000 b497aae1 616e9207 003227a4 '..V....an...2'. >> 00000010: 00000000 00000000 ee36255f 05070201 .........6%_.... >> 00000020: 4c696e75 782d352e 31352e30 2d726335 Linux-5.15.0-rc5 >> 00000030: 2d303232 32342d67 61336330 30376164 -02224-ga3c007ad >> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7 ...........\.p.. >> >> => mw.l 0 0x27051956 >> >> => bootm 0 >> ## Booting kernel from Legacy Image at 00000000 ... >> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >> Image Type: PowerPC Linux Kernel Image (gzip compressed) >> Data Size: 3286948 Bytes = 3.1 MiB >> Load Address: 00000000 >> Entry Point: 00000000 >> Verifying Checksum ... Bad Data CRC >> ERROR: can't get kernel image! >> >> >> So we have something but it seems it gets overwritten by stuff. >> >> Anyway loading a uImage at 0 is just bad because it is a gzipped image that >> should get gunzipped at address 0. >> >> Or should we just copy the raw kernel at 0 and jump to the entry point ? >> But then we also need a device tree somewhere. >> > > If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that address, and > it seems it properly decompress the kernel: > > => bootm 0x1000000 > ## Booting kernel from Legacy Image at 01000000 ... > Image Name: Linux-5.15.0-rc5-02224-ga3c007ad > Image Type: PowerPC Linux Kernel Image (gzip compressed) > Data Size: 3296789 Bytes = 3.1 MiB > Load Address: 00000000 > Entry Point: 00000000 > Verifying Checksum ... OK > Uncompressing Kernel Image ... OK > > > And it initialises the MMU properly. > > Then it gets stuck because there is no devicetree. > > (gdb) bt > #0 0xc00094cc in udelay () > #1 0xc0025d34 in panic () > #2 0xc06415a0 in early_init_devtree () > #3 0xc0641da8 in machine_init () > #4 0xc0002200 in start_here () Maybe you need to embed a dtb in your kernel if that's possible somehow? Or QEMU has a -dtb option that sets machine->dtb but you need board code to do something with it. See how it's done in other boards like virtex_ml507 and sam460ex. But maybe you'd be better off not using -kernel option as it seems to not really working for these 405 boards but load and start the kernel from u-boot. Not sure what device does u-boot support but QEMU can emulate usb-storage, network, different disks so something might work with u-boot if this board has any peripherals. If it doesn't emulate any peripherals what do you expect to do with the kernel once it boots? Regards, BALATON Zoltan
Le 19/10/2021 à 16:56, BALATON Zoltan a écrit : > On Tue, 19 Oct 2021, Christophe Leroy wrote: >> Le 19/10/2021 à 15:44, Christophe Leroy a écrit : >>> There is something: >>> >>> => bootm 0 >>> Wrong Image Format for bootm command >>> ERROR: can't get kernel image! >>> >>> => md 0 >>> 00000000: 00000000 b497aae1 616e9207 003227a4 '..V....an...2'. >>> 00000010: 00000000 00000000 ee36255f 05070201 .........6%_.... >>> 00000020: 4c696e75 782d352e 31352e30 2d726335 Linux-5.15.0-rc5 >>> 00000030: 2d303232 32342d67 61336330 30376164 -02224-ga3c007ad >>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7 ...........\.p.. >>> >>> => mw.l 0 0x27051956 >>> >>> => bootm 0 >>> ## Booting kernel from Legacy Image at 00000000 ... >>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>> Data Size: 3286948 Bytes = 3.1 MiB >>> Load Address: 00000000 >>> Entry Point: 00000000 >>> Verifying Checksum ... Bad Data CRC >>> ERROR: can't get kernel image! >>> >>> >>> So we have something but it seems it gets overwritten by stuff. >>> >>> Anyway loading a uImage at 0 is just bad because it is a gzipped >>> image that should get gunzipped at address 0. >>> >>> Or should we just copy the raw kernel at 0 and jump to the entry >>> point ? But then we also need a device tree somewhere. >>> >> >> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that >> address, and it seems it properly decompress the kernel: >> >> => bootm 0x1000000 >> ## Booting kernel from Legacy Image at 01000000 ... >> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >> Image Type: PowerPC Linux Kernel Image (gzip compressed) >> Data Size: 3296789 Bytes = 3.1 MiB >> Load Address: 00000000 >> Entry Point: 00000000 >> Verifying Checksum ... OK >> Uncompressing Kernel Image ... OK >> >> >> And it initialises the MMU properly. >> >> Then it gets stuck because there is no devicetree. >> >> (gdb) bt >> #0 0xc00094cc in udelay () >> #1 0xc0025d34 in panic () >> #2 0xc06415a0 in early_init_devtree () >> #3 0xc0641da8 in machine_init () >> #4 0xc0002200 in start_here () > > Maybe you need to embed a dtb in your kernel if that's possible somehow? > Or QEMU has a -dtb option that sets machine->dtb but you need board code > to do something with it. See how it's done in other boards like > virtex_ml507 and sam460ex. But maybe you'd be better off not using > -kernel option as it seems to not really working for these 405 boards > but load and start the kernel from u-boot. Not sure what device does > u-boot support but QEMU can emulate usb-storage, network, different > disks so something might work with u-boot if this board has any > peripherals. If it doesn't emulate any peripherals what do you expect to > do with the kernel once it boots? > I should be able to build a multi-FIT image that embeds the kernel and the device tree. I don't know about the peripherals, what I need it a kernel that is able to boot and run some user exe. I'm working on low level functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace protection, etc ... I want to be able to check that after some modifications the kernel can still boot on every CPU sub-family, and I need to run LKDTM tests. For this a kernel + initrd is enough. Thanks Christophe
On 10/19/21 18:12, Christophe Leroy wrote: > > > Le 19/10/2021 à 16:56, BALATON Zoltan a écrit : >> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit : >>>> There is something: >>>> >>>> => bootm 0 >>>> Wrong Image Format for bootm command >>>> ERROR: can't get kernel image! >>>> >>>> => md 0 >>>> 00000000: 00000000 b497aae1 616e9207 003227a4 '..V....an...2'. >>>> 00000010: 00000000 00000000 ee36255f 05070201 .........6%_.... >>>> 00000020: 4c696e75 782d352e 31352e30 2d726335 Linux-5.15.0-rc5 >>>> 00000030: 2d303232 32342d67 61336330 30376164 -02224-ga3c007ad >>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7 ...........\.p.. >>>> >>>> => mw.l 0 0x27051956 >>>> >>>> => bootm 0 >>>> ## Booting kernel from Legacy Image at 00000000 ... >>>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>>> Data Size: 3286948 Bytes = 3.1 MiB >>>> Load Address: 00000000 >>>> Entry Point: 00000000 >>>> Verifying Checksum ... Bad Data CRC >>>> ERROR: can't get kernel image! >>>> >>>> >>>> So we have something but it seems it gets overwritten by stuff. >>>> >>>> Anyway loading a uImage at 0 is just bad because it is a gzipped image that should get gunzipped at address 0. >>>> >>>> Or should we just copy the raw kernel at 0 and jump to the entry point ? But then we also need a device tree somewhere. >>>> >>> >>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that address, and it seems it properly decompress the kernel: >>> >>> => bootm 0x1000000 >>> ## Booting kernel from Legacy Image at 01000000 ... >>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>> Data Size: 3296789 Bytes = 3.1 MiB >>> Load Address: 00000000 >>> Entry Point: 00000000 >>> Verifying Checksum ... OK >>> Uncompressing Kernel Image ... OK >>> >>> >>> And it initialises the MMU properly. >>> >>> Then it gets stuck because there is no devicetree. >>> >>> (gdb) bt >>> #0 0xc00094cc in udelay () >>> #1 0xc0025d34 in panic () >>> #2 0xc06415a0 in early_init_devtree () >>> #3 0xc0641da8 in machine_init () >>> #4 0xc0002200 in start_here () >> >> Maybe you need to embed a dtb in your kernel if that's possible somehow? Or QEMU has a -dtb option that sets machine->dtb but you need board code to do something with it. See how it's done in other boards like virtex_ml507 and sam460ex. But maybe you'd be better off not using -kernel option as it seems to not really working for these 405 boards but load and start the kernel from u-boot. Not sure what device does u-boot support but QEMU can emulate usb-storage, network, different disks so something might work with u-boot if this board has any peripherals. If it doesn't emulate any peripherals what do you expect to do with the kernel once it boots? >> > > I should be able to build a multi-FIT image that embeds the kernel and the device tree. > > I don't know about the peripherals, what I need it a kernel that is able to boot and run some user exe. I'm working on low level functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace protection, etc ... I want to be able to check that after some modifications the kernel can still boot on every CPU sub-family, and I need to run LKDTM tests. > > For this a kernel + initrd is enough. > > Thanks > Christophe If we don't need a loader, we are better off simplifying the 405 boards with a simple init sequence such as : if (machine->kernel_filename) { hwaddr kernel_base = 0; int kernel_size = 0; hwaddr initrd_base = 0; int initrd_size = 0; kernel_size = load_elf(machine->kernel_filename, NULL, NULL, NULL, &boot_entry, &kernel_base, NULL, NULL, 0 /* LE */, PPC_ELF_MACHINE, 0, 0); if (kernel_size < 0) { error_report("Could not load kernel '%s' : %s", machine->kernel_filename, load_elf_strerror(kernel_size)); exit(1); } if (machine->initrd_filename) { initrd_base = QEMU_ALIGN_UP(kernel_base + kernel_size, 0x10000); initrd_size = load_image_targphys(machine->initrd_filename, initrd_base, 16 * MiB /* Some value */); if (initrd_size < 0) { error_report("Could not load initial ram disk '%s'", machine->initrd_filename); exit(1); } } if (machine->dtb) { dt_base = mw_dtb_load(machine, kernel_base, kernel_size, initrd_base, initrd_size); } } We need to set the nip to 'boot_entry' and gpr[3] to 'dt_base'. unless some pre-initialization of hw is required before running Linux ? Thanks, C.
On 10/19/21 18:12, Christophe Leroy wrote: > > > Le 19/10/2021 à 16:56, BALATON Zoltan a écrit : >> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit : >>>> There is something: >>>> >>>> => bootm 0 >>>> Wrong Image Format for bootm command >>>> ERROR: can't get kernel image! >>>> >>>> => md 0 >>>> 00000000: 00000000 b497aae1 616e9207 003227a4 '..V....an...2'. >>>> 00000010: 00000000 00000000 ee36255f 05070201 .........6%_.... >>>> 00000020: 4c696e75 782d352e 31352e30 2d726335 Linux-5.15.0-rc5 >>>> 00000030: 2d303232 32342d67 61336330 30376164 -02224-ga3c007ad >>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7 ...........\.p.. >>>> >>>> => mw.l 0 0x27051956 >>>> >>>> => bootm 0 >>>> ## Booting kernel from Legacy Image at 00000000 ... >>>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>>> Data Size: 3286948 Bytes = 3.1 MiB >>>> Load Address: 00000000 >>>> Entry Point: 00000000 >>>> Verifying Checksum ... Bad Data CRC >>>> ERROR: can't get kernel image! >>>> >>>> >>>> So we have something but it seems it gets overwritten by stuff. >>>> >>>> Anyway loading a uImage at 0 is just bad because it is a gzipped image that should get gunzipped at address 0. >>>> >>>> Or should we just copy the raw kernel at 0 and jump to the entry point ? But then we also need a device tree somewhere. >>>> >>> >>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that address, and it seems it properly decompress the kernel: >>> >>> => bootm 0x1000000 >>> ## Booting kernel from Legacy Image at 01000000 ... >>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>> Data Size: 3296789 Bytes = 3.1 MiB >>> Load Address: 00000000 >>> Entry Point: 00000000 >>> Verifying Checksum ... OK >>> Uncompressing Kernel Image ... OK >>> >>> >>> And it initialises the MMU properly. >>> >>> Then it gets stuck because there is no devicetree. >>> >>> (gdb) bt >>> #0 0xc00094cc in udelay () >>> #1 0xc0025d34 in panic () >>> #2 0xc06415a0 in early_init_devtree () >>> #3 0xc0641da8 in machine_init () >>> #4 0xc0002200 in start_here () >> >> Maybe you need to embed a dtb in your kernel if that's possible somehow? Or QEMU has a -dtb option that sets machine->dtb but you need board code to do something with it. See how it's done in other boards like virtex_ml507 and sam460ex. But maybe you'd be better off not using -kernel option as it seems to not really working for these 405 boards but load and start the kernel from u-boot. Not sure what device does u-boot support but QEMU can emulate usb-storage, network, different disks so something might work with u-boot if this board has any peripherals. If it doesn't emulate any peripherals what do you expect to do with the kernel once it boots? >> > > I should be able to build a multi-FIT image that embeds the kernel and the device tree. > > I don't know about the peripherals, what I need it a kernel that is able to boot and run some user exe. I'm working on low level functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace protection, etc ... I want to be able to check that after some modifications the kernel can still boot on every CPU sub-family, and I need to run LKDTM tests. > > For this a kernel + initrd is enough. hotfoot.dts is the only DT with a CPU model "PowerPC,405EP". With cuImage.hotfoot, U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200) CPU: AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128) I2C boot EEPROM disabled Internal PCI arbiter enabled 16 KiB I-Cache 16 KiB D-Cache Board: Taihu - AMCC PPC405EP Evaluation Board I2C: ready DRAM: 128 MiB Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB 0 Bytes *** Warning - bad CRC, using default environment PCI: Bus Dev VenId DevId Class Int PCI: Net: No ethernet found. Type run flash_nfs to mount root filesystem over NFS Hit any key to stop autoboot: 0 => bootm 01000000 ## Booting kernel from Legacy Image at 01000000 ... Image Name: Linux-5.15.0-rc6-dirty Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 3326878 Bytes = 3.2 MiB Load Address: 00700000 Entry Point: 00701aa8 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory <- <0x0 0x8000000> (128MB) CPU clock-frequency <- 0x0 (0MHz) CPU timebase-frequency <- 0x0 (0MHz) /plb: clock-frequency <- 0 (0MHz) /plb/opb: clock-frequency <- 0 (0MHz) /plb/ebc: clock-frequency <- 0 (0MHz) /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz) /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz) ethernet0: local-mac-address <- 00:00:00:00:00:00 ethernet1: local-mac-address <- 00:00:2d:e5:44:80 Fixing devtree for 4M Flash zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0) Decompression error: 'Not a gzip file' No valid compressed data found, assume uncompressed data Allocating 0x6c128c bytes for kernel... 0x69e1ec bytes of uncompressed data copied Linux/PowerPC load: Finalizing device tree... flat tree at 0xdc5960 Linux version 5.15.0-rc6-dirty (legoater@yukon) (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1), GNU ld version 2.35.2-1.fc34) #1 Tue Oct 19 15:15:21 CEST 2021 Using PowerPC 40x Platform machine description printk: bootconsole [udbg0] enabled ----------------------------------------------------- phys_mem_size = 0x8000000 dcache_bsize = 0x20 icache_bsize = 0x20 cpu_features = 0x0000000000000100 possible = 0x0000000000000100 always = 0x0000000000000100 cpu_user_features = 0x86000000 0x00000000 mmu_features = 0x00000004 ----------------------------------------------------- Zone ranges: Normal [mem 0x0000000000000000-0x0000000007ffffff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000000000000-0x0000000007ffffff] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists, mobility grouping on. Total pages: 32512 Kernel command line: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) mem auto-init: stack:off, heap alloc:off, heap free:off Kernel virtual memory layout: * 0xffbdf000..0xfffff000 : fixmap * 0xc9000000..0xffbdf000 : vmalloc & ioremap Memory: 122948K/131072K available (5040K kernel code, 220K rwdata, 1320K rodata, 200K init, 136K bss, 8124K reserved, 0K cma-reserved) SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 UIC0 (32 IRQ sources) at DCR 0xc0 random: get_random_u32 called from start_kernel+0x498/0x5f8 with crng_init=0
Le 19/10/2021 à 23:30, Cédric Le Goater a écrit : > On 10/19/21 18:12, Christophe Leroy wrote: >> >> >> Le 19/10/2021 à 16:56, BALATON Zoltan a écrit : >>> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit : >>>>> There is something: >>>>> >>>>> => bootm 0 >>>>> Wrong Image Format for bootm command >>>>> ERROR: can't get kernel image! >>>>> >>>>> => md 0 >>>>> 00000000: 00000000 b497aae1 616e9207 003227a4 '..V....an...2'. >>>>> 00000010: 00000000 00000000 ee36255f 05070201 .........6%_.... >>>>> 00000020: 4c696e75 782d352e 31352e30 2d726335 Linux-5.15.0-rc5 >>>>> 00000030: 2d303232 32342d67 61336330 30376164 -02224-ga3c007ad >>>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7 ...........\.p.. >>>>> >>>>> => mw.l 0 0x27051956 >>>>> >>>>> => bootm 0 >>>>> ## Booting kernel from Legacy Image at 00000000 ... >>>>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>>>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>>>> Data Size: 3286948 Bytes = 3.1 MiB >>>>> Load Address: 00000000 >>>>> Entry Point: 00000000 >>>>> Verifying Checksum ... Bad Data CRC >>>>> ERROR: can't get kernel image! >>>>> >>>>> >>>>> So we have something but it seems it gets overwritten by stuff. >>>>> >>>>> Anyway loading a uImage at 0 is just bad because it is a gzipped >>>>> image that should get gunzipped at address 0. >>>>> >>>>> Or should we just copy the raw kernel at 0 and jump to the entry >>>>> point ? But then we also need a device tree somewhere. >>>>> >>>> >>>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that >>>> address, and it seems it properly decompress the kernel: >>>> >>>> => bootm 0x1000000 >>>> ## Booting kernel from Legacy Image at 01000000 ... >>>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>>> Data Size: 3296789 Bytes = 3.1 MiB >>>> Load Address: 00000000 >>>> Entry Point: 00000000 >>>> Verifying Checksum ... OK >>>> Uncompressing Kernel Image ... OK >>>> >>>> >>>> And it initialises the MMU properly. >>>> >>>> Then it gets stuck because there is no devicetree. >>>> >>>> (gdb) bt >>>> #0 0xc00094cc in udelay () >>>> #1 0xc0025d34 in panic () >>>> #2 0xc06415a0 in early_init_devtree () >>>> #3 0xc0641da8 in machine_init () >>>> #4 0xc0002200 in start_here () >>> >>> Maybe you need to embed a dtb in your kernel if that's possible >>> somehow? Or QEMU has a -dtb option that sets machine->dtb but you >>> need board code to do something with it. See how it's done in other >>> boards like virtex_ml507 and sam460ex. But maybe you'd be better off >>> not using -kernel option as it seems to not really working for these >>> 405 boards but load and start the kernel from u-boot. Not sure what >>> device does u-boot support but QEMU can emulate usb-storage, network, >>> different disks so something might work with u-boot if this board has >>> any peripherals. If it doesn't emulate any peripherals what do you >>> expect to do with the kernel once it boots? >>> >> >> I should be able to build a multi-FIT image that embeds the kernel and >> the device tree. >> >> I don't know about the peripherals, what I need it a kernel that is >> able to boot and run some user exe. I'm working on low level >> functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace >> protection, etc ... I want to be able to check that after some >> modifications the kernel can still boot on every CPU sub-family, and I >> need to run LKDTM tests. >> >> For this a kernel + initrd is enough. > > hotfoot.dts is the only DT with a CPU model "PowerPC,405EP". > > With cuImage.hotfoot, > > U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200) > > CPU: AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128) > I2C boot EEPROM disabled > Internal PCI arbiter enabled > 16 KiB I-Cache 16 KiB D-Cache > Board: Taihu - AMCC PPC405EP Evaluation Board > I2C: ready > DRAM: 128 MiB > Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB > ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB > 0 Bytes > *** Warning - bad CRC, using default environment > > PCI: Bus Dev VenId DevId Class Int > PCI: > Net: No ethernet found. > > Type run flash_nfs to mount root filesystem over NFS > > Hit any key to stop autoboot: 0 > => bootm 01000000 > ## Booting kernel from Legacy Image at 01000000 ... > Image Name: Linux-5.15.0-rc6-dirty > Image Type: PowerPC Linux Kernel Image (gzip compressed) > Data Size: 3326878 Bytes = 3.2 MiB > Load Address: 00700000 > Entry Point: 00701aa8 > Verifying Checksum ... OK > Uncompressing Kernel Image ... OK > Memory <- <0x0 0x8000000> (128MB) > CPU clock-frequency <- 0x0 (0MHz) > CPU timebase-frequency <- 0x0 (0MHz) > /plb: clock-frequency <- 0 (0MHz) > /plb/opb: clock-frequency <- 0 (0MHz) > /plb/ebc: clock-frequency <- 0 (0MHz) > /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz) > /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz) > ethernet0: local-mac-address <- 00:00:00:00:00:00 > ethernet1: local-mac-address <- 00:00:2d:e5:44:80 > Fixing devtree for 4M Flash > > zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0) > Decompression error: 'Not a gzip file' > No valid compressed data found, assume uncompressed data > Allocating 0x6c128c bytes for kernel... > 0x69e1ec bytes of uncompressed data copied > > Linux/PowerPC load: > Finalizing device tree... flat tree at 0xdc5960 > Linux version 5.15.0-rc6-dirty (legoater@yukon) (powerpc64-linux-gnu-gcc > (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1), GNU ld version > 2.35.2-1.fc34) #1 Tue Oct 19 15:15:21 CEST 2021 > Using PowerPC 40x Platform machine description > printk: bootconsole [udbg0] enabled > ----------------------------------------------------- > phys_mem_size = 0x8000000 > dcache_bsize = 0x20 > icache_bsize = 0x20 > cpu_features = 0x0000000000000100 > possible = 0x0000000000000100 > always = 0x0000000000000100 > cpu_user_features = 0x86000000 0x00000000 > mmu_features = 0x00000004 > ----------------------------------------------------- > Zone ranges: > Normal [mem 0x0000000000000000-0x0000000007ffffff] > Movable zone start for each node > Early memory node ranges > node 0: [mem 0x0000000000000000-0x0000000007ffffff] > Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] > MMU: Allocated 1088 bytes of context maps for 255 contexts > Built 1 zonelists, mobility grouping on. Total pages: 32512 > Kernel command line: > Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) > Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) > mem auto-init: stack:off, heap alloc:off, heap free:off > Kernel virtual memory layout: > * 0xffbdf000..0xfffff000 : fixmap > * 0xc9000000..0xffbdf000 : vmalloc & ioremap > Memory: 122948K/131072K available (5040K kernel code, 220K rwdata, 1320K > rodata, 200K init, 136K bss, 8124K reserved, 0K cma-reserved) > SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 > UIC0 (32 IRQ sources) at DCR 0xc0 > random: get_random_u32 called from start_kernel+0x498/0x5f8 with > crng_init=0 > Great. (gdb) bt #0 __div64_32 () at arch/powerpc/lib/div64.S:29 #1 0xc00099bc in div128_by_32 (dividend_high=<optimized out>, dividend_low=<optimized out>, divisor=<optimized out>, dr=dr@entry=0xc0693f78) at arch/powerpc/kernel/time.c:1038 #2 0xc0641060 in time_init () at arch/powerpc/kernel/time.c:978 #3 0xc063dc48 in start_kernel () at init/main.c:1055 #4 0xc0002204 in start_here () at arch/powerpc/kernel/head_40x.S:617 Looping forever in __div64_32() due to: > CPU clock-frequency <- 0x0 (0MHz) > CPU timebase-frequency <- 0x0 (0MHz) > /plb: clock-frequency <- 0 (0MHz) > /plb/opb: clock-frequency <- 0 (0MHz) > /plb/ebc: clock-frequency <- 0 (0MHz) > /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz) > /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz) Christophe
On 10/20/21 11:02, Christophe Leroy wrote: > > > Le 19/10/2021 à 23:30, Cédric Le Goater a écrit : >> On 10/19/21 18:12, Christophe Leroy wrote: >>> >>> >>> Le 19/10/2021 à 16:56, BALATON Zoltan a écrit : >>>> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>>>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit : >>>>>> There is something: >>>>>> >>>>>> => bootm 0 >>>>>> Wrong Image Format for bootm command >>>>>> ERROR: can't get kernel image! >>>>>> >>>>>> => md 0 >>>>>> 00000000: 00000000 b497aae1 616e9207 003227a4 '..V....an...2'. >>>>>> 00000010: 00000000 00000000 ee36255f 05070201 .........6%_.... >>>>>> 00000020: 4c696e75 782d352e 31352e30 2d726335 Linux-5.15.0-rc5 >>>>>> 00000030: 2d303232 32342d67 61336330 30376164 -02224-ga3c007ad >>>>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7 ...........\.p.. >>>>>> >>>>>> => mw.l 0 0x27051956 >>>>>> >>>>>> => bootm 0 >>>>>> ## Booting kernel from Legacy Image at 00000000 ... >>>>>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>>>>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>>>>> Data Size: 3286948 Bytes = 3.1 MiB >>>>>> Load Address: 00000000 >>>>>> Entry Point: 00000000 >>>>>> Verifying Checksum ... Bad Data CRC >>>>>> ERROR: can't get kernel image! >>>>>> >>>>>> >>>>>> So we have something but it seems it gets overwritten by stuff. >>>>>> >>>>>> Anyway loading a uImage at 0 is just bad because it is a gzipped image that should get gunzipped at address 0. >>>>>> >>>>>> Or should we just copy the raw kernel at 0 and jump to the entry point ? But then we also need a device tree somewhere. >>>>>> >>>>> >>>>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that address, and it seems it properly decompress the kernel: >>>>> >>>>> => bootm 0x1000000 >>>>> ## Booting kernel from Legacy Image at 01000000 ... >>>>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>>>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>>>> Data Size: 3296789 Bytes = 3.1 MiB >>>>> Load Address: 00000000 >>>>> Entry Point: 00000000 >>>>> Verifying Checksum ... OK >>>>> Uncompressing Kernel Image ... OK >>>>> >>>>> >>>>> And it initialises the MMU properly. >>>>> >>>>> Then it gets stuck because there is no devicetree. >>>>> >>>>> (gdb) bt >>>>> #0 0xc00094cc in udelay () >>>>> #1 0xc0025d34 in panic () >>>>> #2 0xc06415a0 in early_init_devtree () >>>>> #3 0xc0641da8 in machine_init () >>>>> #4 0xc0002200 in start_here () >>>> >>>> Maybe you need to embed a dtb in your kernel if that's possible somehow? Or QEMU has a -dtb option that sets machine->dtb but you need board code to do something with it. See how it's done in other boards like virtex_ml507 and sam460ex. But maybe you'd be better off not using -kernel option as it seems to not really working for these 405 boards but load and start the kernel from u-boot. Not sure what device does u-boot support but QEMU can emulate usb-storage, network, different disks so something might work with u-boot if this board has any peripherals. If it doesn't emulate any peripherals what do you expect to do with the kernel once it boots? >>>> >>> >>> I should be able to build a multi-FIT image that embeds the kernel and the device tree. >>> >>> I don't know about the peripherals, what I need it a kernel that is able to boot and run some user exe. I'm working on low level functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace protection, etc ... I want to be able to check that after some modifications the kernel can still boot on every CPU sub-family, and I need to run LKDTM tests. >>> >>> For this a kernel + initrd is enough. >> >> hotfoot.dts is the only DT with a CPU model "PowerPC,405EP". >> >> With cuImage.hotfoot, >> >> U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200) >> >> CPU: AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128) >> I2C boot EEPROM disabled >> Internal PCI arbiter enabled >> 16 KiB I-Cache 16 KiB D-Cache >> Board: Taihu - AMCC PPC405EP Evaluation Board >> I2C: ready >> DRAM: 128 MiB >> Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB >> ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB >> 0 Bytes >> *** Warning - bad CRC, using default environment >> >> PCI: Bus Dev VenId DevId Class Int >> PCI: >> Net: No ethernet found. >> >> Type run flash_nfs to mount root filesystem over NFS >> >> Hit any key to stop autoboot: 0 >> => bootm 01000000 >> ## Booting kernel from Legacy Image at 01000000 ... >> Image Name: Linux-5.15.0-rc6-dirty >> Image Type: PowerPC Linux Kernel Image (gzip compressed) >> Data Size: 3326878 Bytes = 3.2 MiB >> Load Address: 00700000 >> Entry Point: 00701aa8 >> Verifying Checksum ... OK >> Uncompressing Kernel Image ... OK >> Memory <- <0x0 0x8000000> (128MB) >> CPU clock-frequency <- 0x0 (0MHz) >> CPU timebase-frequency <- 0x0 (0MHz) >> /plb: clock-frequency <- 0 (0MHz) >> /plb/opb: clock-frequency <- 0 (0MHz) >> /plb/ebc: clock-frequency <- 0 (0MHz) >> /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz) >> /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz) >> ethernet0: local-mac-address <- 00:00:00:00:00:00 >> ethernet1: local-mac-address <- 00:00:2d:e5:44:80 >> Fixing devtree for 4M Flash >> >> zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0) >> Decompression error: 'Not a gzip file' >> No valid compressed data found, assume uncompressed data >> Allocating 0x6c128c bytes for kernel... >> 0x69e1ec bytes of uncompressed data copied >> >> Linux/PowerPC load: >> Finalizing device tree... flat tree at 0xdc5960 >> Linux version 5.15.0-rc6-dirty (legoater@yukon) (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1), GNU ld version 2.35.2-1.fc34) #1 Tue Oct 19 15:15:21 CEST 2021 >> Using PowerPC 40x Platform machine description >> printk: bootconsole [udbg0] enabled >> ----------------------------------------------------- >> phys_mem_size = 0x8000000 >> dcache_bsize = 0x20 >> icache_bsize = 0x20 >> cpu_features = 0x0000000000000100 >> possible = 0x0000000000000100 >> always = 0x0000000000000100 >> cpu_user_features = 0x86000000 0x00000000 >> mmu_features = 0x00000004 >> ----------------------------------------------------- >> Zone ranges: >> Normal [mem 0x0000000000000000-0x0000000007ffffff] >> Movable zone start for each node >> Early memory node ranges >> node 0: [mem 0x0000000000000000-0x0000000007ffffff] >> Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] >> MMU: Allocated 1088 bytes of context maps for 255 contexts >> Built 1 zonelists, mobility grouping on. Total pages: 32512 >> Kernel command line: >> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) >> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) >> mem auto-init: stack:off, heap alloc:off, heap free:off >> Kernel virtual memory layout: >> * 0xffbdf000..0xfffff000 : fixmap >> * 0xc9000000..0xffbdf000 : vmalloc & ioremap >> Memory: 122948K/131072K available (5040K kernel code, 220K rwdata, 1320K rodata, 200K init, 136K bss, 8124K reserved, 0K cma-reserved) >> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 >> NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 >> UIC0 (32 IRQ sources) at DCR 0xc0 >> random: get_random_u32 called from start_kernel+0x498/0x5f8 with crng_init=0 >> > > Great. > > (gdb) bt > #0 __div64_32 () at arch/powerpc/lib/div64.S:29 > #1 0xc00099bc in div128_by_32 (dividend_high=<optimized out>, dividend_low=<optimized out>, divisor=<optimized out>, dr=dr@entry=0xc0693f78) at arch/powerpc/kernel/time.c:1038 > #2 0xc0641060 in time_init () at arch/powerpc/kernel/time.c:978 > #3 0xc063dc48 in start_kernel () at init/main.c:1055 > #4 0xc0002204 in start_here () at arch/powerpc/kernel/head_40x.S:617 > > > Looping forever in __div64_32() due to: > > > CPU clock-frequency <- 0x0 (0MHz) > > CPU timebase-frequency <- 0x0 (0MHz) > > /plb: clock-frequency <- 0 (0MHz) > > /plb/opb: clock-frequency <- 0 (0MHz) > > /plb/ebc: clock-frequency <- 0 (0MHz) > > /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz) > > /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz) I dont understand how static bd_t bd; can be updated in the kernel. C.
Hi John / Paolo / Markus, On 10/19/21 12:07, BALATON Zoltan wrote: > On Tue, 19 Oct 2021, Christophe Leroy wrote: >> Le 19/10/2021 à 11:39, Thomas Huth a écrit : >>> On 19/10/2021 11.31, Christophe Leroy wrote: [...] >> I use the following command, but it does nothing, it stays in uboot >> prompt as when I don't get a kernel argument >> >> ~/qemu/build/qemu-system-ppc -M taihu -bios >> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel >> arch/powerpc/boot/uImage > > I'm not sure using -bios and -kernel together makes sense, it probably > starts u-boot in this case and you have to load and start the kernel > from u-boot as you'd notmally do on a real machine. Alternatively you > could use -kernel instead of -bios which then loads a kernel and starts > it directly but not sure if it needs a firmware to work. > > Ot I could be completely wrong as I don't know this machine and haven't > tried it. Usually -bios overwrites -kernel/-append cmdline options. Having them accepted together is probably a configuration mistake, and we should reject that (generically). You guys have been working on the CLI recently, is there an easy way to not allow such combination? Thanks, Phil.
On 10/19/21 13:11, Thomas Huth wrote: > On 19/10/2021 12.07, BALATON Zoltan wrote: >> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>> Le 19/10/2021 à 11:39, Thomas Huth a écrit : >>>> On 19/10/2021 11.31, Christophe Leroy wrote: >>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit : >>>>>> On 11/10/2021 11.20, David Gibson wrote: >>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote: >>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>>>>>>> [...] >>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware >>>>>>>>>> where the >>>>>>>>>> memory detection was patched out but it seems to detect the >>>>>>>>>> RAM so I >>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure >>>>>>>>>> what >>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe >>>>>>>>>> for the speed calibration, so could be it detects ram by reading >>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as >>>>>>>>>> i2c is >>>>>>>>>> not emulated on taihu. This could be confirmed by checking >>>>>>>>>> what it >>>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices >>>>>>>>>> but don't know where 405 has the i2c controller and if it's >>>>>>>>>> the same >>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be >>>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy >>>>>>>>>> or you >>>>>>>>>> could skip this in u-boot. >>>>>>>>> >>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in >>>>>>>>> u-boot), >>>>>>>>> and indeed, I can get to the u-boot prompt now. >>>>>>>> [...]> I've also attached the patch with my modifications to >>>>>>>> u-boot. >>>>>>>> >>>>>>>> FYI, the changes can now be found on this branch here: >>>>>>>> >>>>>>>> https://gitlab.com/huth/u-boot/-/commits/taihu >>>>>>>> >>>>>>>> I also added a gitlab-CI file, so you can now download the >>>>>>>> u-boot.bin as an >>>>>>>> artifact from the corresponding pipeline, e.g.: >>>>>>>> >>>>>>>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Are you going to send a v2 of your proposed deprecation patches? >>>>>> >>>>>> No, since there was interest in keeping the 405 boards for testing >>>>>> the 405 code in the Linux kernel, and since there is now a way to >>>>>> do at least some very basic testing of these boards (with the >>>>>> u-boot firmware), I don't plan to respin the deprecation patch. I >>>>>> just sent a patch for adding the boards to our CI instead: >>>>>> >>>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html >>>>>> >>>>> >>>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 >>>>> and mainline, and I get: >>>>> >>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>> Bail out! >>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>> Abandon (core dumped) >>>>> >>>>> I see in the mail history that you got that problem as well at some >>>>> point. How did you fix it ? >>>> >>>> You need this patch here to fix this issue: >>>> >>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html >>>> ("hw/ppc: Fix iothread locking in the 405 code") >>>> >>> >>> Thank you. >>> >>> Is there anything special to do then in order to boot a Linux kernel ? >>> >>> I build the uImage for ppc40x_defconfig >>> >>> I use the following command, but it does nothing, it stays in uboot >>> prompt as when I don't get a kernel argument >>> >>> ~/qemu/build/qemu-system-ppc -M taihu -bios >>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel >>> arch/powerpc/boot/uImage >> >> I'm not sure using -bios and -kernel together makes sense, it probably >> starts u-boot in this case and you have to load and start the kernel >> from u-boot as you'd notmally do on a real machine. Alternatively you >> could use -kernel instead of -bios which then loads a kernel and >> starts it directly but not sure if it needs a firmware to work. >> >> Ot I could be completely wrong as I don't know this machine and >> haven't tried it. > > Actually, these 405 machines are quite weird. They refuse to boot > without bios image, so you currently need the firmware image for sure. When using -kernel/-append, if a BIOS is required by the kernel, then it should be crafted by the machine IMO. Usually OS only access a configuration area in PROM. The PROM must be mapped, and the minimum configuration structure filled. Anyhow I find -bios confusing, I never know if this option parse or expects a full/partial raw flash image, an ELF image, something else...
+Richard 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?
On 20/10/2021 12.12, Philippe Mathieu-Daudé wrote: > Hi John / Paolo / Markus, > > On 10/19/21 12:07, BALATON Zoltan wrote: >> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>> Le 19/10/2021 à 11:39, Thomas Huth a écrit : >>>> On 19/10/2021 11.31, Christophe Leroy wrote: > [...] >>> I use the following command, but it does nothing, it stays in uboot >>> prompt as when I don't get a kernel argument >>> >>> ~/qemu/build/qemu-system-ppc -M taihu -bios >>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel >>> arch/powerpc/boot/uImage >> >> I'm not sure using -bios and -kernel together makes sense, it probably >> starts u-boot in this case and you have to load and start the kernel >> from u-boot as you'd notmally do on a real machine. Alternatively you >> could use -kernel instead of -bios which then loads a kernel and starts >> it directly but not sure if it needs a firmware to work. >> >> Ot I could be completely wrong as I don't know this machine and haven't >> tried it. > > Usually -bios overwrites -kernel/-append cmdline options. > Having them accepted together is probably a configuration mistake, > and we should reject that (generically). No, having -bios and -kernel together is perfectly fine if the BIOS knows about it. Have a look at the ppc64 pseries machine, it works perfectly fine with -bios and -kernel at the same time. Thomas
On Wed, 20 Oct 2021, Thomas Huth wrote: > On 20/10/2021 12.12, Philippe Mathieu-Daudé wrote: >> Hi John / Paolo / Markus, >> >> On 10/19/21 12:07, BALATON Zoltan wrote: >>> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit : >>>>> On 19/10/2021 11.31, Christophe Leroy wrote: >> [...] >>>> I use the following command, but it does nothing, it stays in uboot >>>> prompt as when I don't get a kernel argument >>>> >>>> ~/qemu/build/qemu-system-ppc -M taihu -bios >>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel >>>> arch/powerpc/boot/uImage >>> >>> I'm not sure using -bios and -kernel together makes sense, it probably >>> starts u-boot in this case and you have to load and start the kernel >>> from u-boot as you'd notmally do on a real machine. Alternatively you >>> could use -kernel instead of -bios which then loads a kernel and starts >>> it directly but not sure if it needs a firmware to work. >>> >>> Ot I could be completely wrong as I don't know this machine and haven't >>> tried it. >> >> Usually -bios overwrites -kernel/-append cmdline options. >> Having them accepted together is probably a configuration mistake, >> and we should reject that (generically). > > No, having -bios and -kernel together is perfectly fine if the BIOS knows > about it. Have a look at the ppc64 pseries machine, it works perfectly fine > with -bios and -kernel at the same time. Also this way the board can decide what's right, In pegasos2 I added a warning for cases that may not work as expected to let users know but on other machines a firmware may be needed and -kernel could set firmware environment to boot that loaded kernel (this may be what ref405 is trying to do or e500 also messes with some boot_info struct that it writes to guest I think). So maybe there's no generic way to handle it. These options are just defined by the board which is not great for UI consistency but may be needed for enough flexibility to implement everything boards want. Regards, BALATON Zoltan
On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote: > On 10/19/21 13:11, Thomas Huth wrote: >> On 19/10/2021 12.07, BALATON Zoltan wrote: >>> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit : >>>>> On 19/10/2021 11.31, Christophe Leroy wrote: >>>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit : >>>>>>> On 11/10/2021 11.20, David Gibson wrote: >>>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote: >>>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>>>>>>>> [...] >>>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware >>>>>>>>>>> where the >>>>>>>>>>> memory detection was patched out but it seems to detect the >>>>>>>>>>> RAM so I >>>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure >>>>>>>>>>> what >>>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe >>>>>>>>>>> for the speed calibration, so could be it detects ram by reading >>>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as >>>>>>>>>>> i2c is >>>>>>>>>>> not emulated on taihu. This could be confirmed by checking >>>>>>>>>>> what it >>>>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices >>>>>>>>>>> but don't know where 405 has the i2c controller and if it's >>>>>>>>>>> the same >>>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be >>>>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy >>>>>>>>>>> or you >>>>>>>>>>> could skip this in u-boot. >>>>>>>>>> >>>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in >>>>>>>>>> u-boot), >>>>>>>>>> and indeed, I can get to the u-boot prompt now. >>>>>>>>> [...]> I've also attached the patch with my modifications to >>>>>>>>> u-boot. >>>>>>>>> >>>>>>>>> FYI, the changes can now be found on this branch here: >>>>>>>>> >>>>>>>>> https://gitlab.com/huth/u-boot/-/commits/taihu >>>>>>>>> >>>>>>>>> I also added a gitlab-CI file, so you can now download the >>>>>>>>> u-boot.bin as an >>>>>>>>> artifact from the corresponding pipeline, e.g.: >>>>>>>>> >>>>>>>>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Are you going to send a v2 of your proposed deprecation patches? >>>>>>> >>>>>>> No, since there was interest in keeping the 405 boards for testing >>>>>>> the 405 code in the Linux kernel, and since there is now a way to >>>>>>> do at least some very basic testing of these boards (with the >>>>>>> u-boot firmware), I don't plan to respin the deprecation patch. I >>>>>>> just sent a patch for adding the boards to our CI instead: >>>>>>> >>>>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html >>>>>>> >>>>>> >>>>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 >>>>>> and mainline, and I get: >>>>>> >>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>>> Bail out! >>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>>> Abandon (core dumped) >>>>>> >>>>>> I see in the mail history that you got that problem as well at some >>>>>> point. How did you fix it ? >>>>> >>>>> You need this patch here to fix this issue: >>>>> >>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html >>>>> ("hw/ppc: Fix iothread locking in the 405 code") >>>>> >>>> >>>> Thank you. >>>> >>>> Is there anything special to do then in order to boot a Linux kernel ? >>>> >>>> I build the uImage for ppc40x_defconfig >>>> >>>> I use the following command, but it does nothing, it stays in uboot >>>> prompt as when I don't get a kernel argument >>>> >>>> ~/qemu/build/qemu-system-ppc -M taihu -bios >>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel >>>> arch/powerpc/boot/uImage >>> >>> I'm not sure using -bios and -kernel together makes sense, it probably >>> starts u-boot in this case and you have to load and start the kernel >>> from u-boot as you'd notmally do on a real machine. Alternatively you >>> could use -kernel instead of -bios which then loads a kernel and >>> starts it directly but not sure if it needs a firmware to work. >>> >>> Ot I could be completely wrong as I don't know this machine and >>> haven't tried it. >> >> Actually, these 405 machines are quite weird. They refuse to boot >> without bios image, so you currently need the firmware image for sure. > > When using -kernel/-append, if a BIOS is required by the kernel, > then it should be crafted by the machine IMO. Usually OS only > access a configuration area in PROM. The PROM must be mapped, > and the minimum configuration structure filled. > > Anyhow I find -bios confusing, I never know if this option parse > or expects a full/partial raw flash image, an ELF image, something > else... Generally a firmware image in whatever format the board expects. Usually raw binary or ELF. Not that different from -kernel that also takes different formats depending on the machine. Think of -bios like -kernel for firmware, i.e. specifying what firmware to use like -kernel specifies what kernel to use. Regards, BALATON Zoltan
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. Regards, BALATON Zoltan
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. Thanks, C. > > Regards, > BALATON Zoltan
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.
Le 20/10/2021 à 12:10, Cédric Le Goater a écrit : > On 10/20/21 11:02, Christophe Leroy wrote: >> >> >> Le 19/10/2021 à 23:30, Cédric Le Goater a écrit : >>> On 10/19/21 18:12, Christophe Leroy wrote: >>>> >>>> >>>> Le 19/10/2021 à 16:56, BALATON Zoltan a écrit : >>>>> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>>>>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit : >>>>>>> There is something: >>>>>>> >>>>>>> => bootm 0 >>>>>>> Wrong Image Format for bootm command >>>>>>> ERROR: can't get kernel image! >>>>>>> >>>>>>> => md 0 >>>>>>> 00000000: 00000000 b497aae1 616e9207 003227a4 '..V....an...2'. >>>>>>> 00000010: 00000000 00000000 ee36255f 05070201 .........6%_.... >>>>>>> 00000020: 4c696e75 782d352e 31352e30 2d726335 Linux-5.15.0-rc5 >>>>>>> 00000030: 2d303232 32342d67 61336330 30376164 -02224-ga3c007ad >>>>>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7 ...........\.p.. >>>>>>> >>>>>>> => mw.l 0 0x27051956 >>>>>>> >>>>>>> => bootm 0 >>>>>>> ## Booting kernel from Legacy Image at 00000000 ... >>>>>>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>>>>>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>>>>>> Data Size: 3286948 Bytes = 3.1 MiB >>>>>>> Load Address: 00000000 >>>>>>> Entry Point: 00000000 >>>>>>> Verifying Checksum ... Bad Data CRC >>>>>>> ERROR: can't get kernel image! >>>>>>> >>>>>>> >>>>>>> So we have something but it seems it gets overwritten by stuff. >>>>>>> >>>>>>> Anyway loading a uImage at 0 is just bad because it is a gzipped >>>>>>> image that should get gunzipped at address 0. >>>>>>> >>>>>>> Or should we just copy the raw kernel at 0 and jump to the entry >>>>>>> point ? But then we also need a device tree somewhere. >>>>>>> >>>>>> >>>>>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that >>>>>> address, and it seems it properly decompress the kernel: >>>>>> >>>>>> => bootm 0x1000000 >>>>>> ## Booting kernel from Legacy Image at 01000000 ... >>>>>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>>>>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>>>>> Data Size: 3296789 Bytes = 3.1 MiB >>>>>> Load Address: 00000000 >>>>>> Entry Point: 00000000 >>>>>> Verifying Checksum ... OK >>>>>> Uncompressing Kernel Image ... OK >>>>>> >>>>>> >>>>>> And it initialises the MMU properly. >>>>>> >>>>>> Then it gets stuck because there is no devicetree. >>>>>> >>>>>> (gdb) bt >>>>>> #0 0xc00094cc in udelay () >>>>>> #1 0xc0025d34 in panic () >>>>>> #2 0xc06415a0 in early_init_devtree () >>>>>> #3 0xc0641da8 in machine_init () >>>>>> #4 0xc0002200 in start_here () >>>>> >>>>> Maybe you need to embed a dtb in your kernel if that's possible >>>>> somehow? Or QEMU has a -dtb option that sets machine->dtb but you >>>>> need board code to do something with it. See how it's done in other >>>>> boards like virtex_ml507 and sam460ex. But maybe you'd be better >>>>> off not using -kernel option as it seems to not really working for >>>>> these 405 boards but load and start the kernel from u-boot. Not >>>>> sure what device does u-boot support but QEMU can emulate >>>>> usb-storage, network, different disks so something might work with >>>>> u-boot if this board has any peripherals. If it doesn't emulate any >>>>> peripherals what do you expect to do with the kernel once it boots? >>>>> >>>> >>>> I should be able to build a multi-FIT image that embeds the kernel >>>> and the device tree. >>>> >>>> I don't know about the peripherals, what I need it a kernel that is >>>> able to boot and run some user exe. I'm working on low level >>>> functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace >>>> protection, etc ... I want to be able to check that after some >>>> modifications the kernel can still boot on every CPU sub-family, and >>>> I need to run LKDTM tests. >>>> >>>> For this a kernel + initrd is enough. >>> >>> hotfoot.dts is the only DT with a CPU model "PowerPC,405EP". >>> >>> With cuImage.hotfoot, >>> >>> U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200) >>> >>> CPU: AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128) >>> I2C boot EEPROM disabled >>> Internal PCI arbiter enabled >>> 16 KiB I-Cache 16 KiB D-Cache >>> Board: Taihu - AMCC PPC405EP Evaluation Board >>> I2C: ready >>> DRAM: 128 MiB >>> Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB >>> ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB >>> 0 Bytes >>> *** Warning - bad CRC, using default environment >>> >>> PCI: Bus Dev VenId DevId Class Int >>> PCI: >>> Net: No ethernet found. >>> >>> Type run flash_nfs to mount root filesystem over NFS >>> >>> Hit any key to stop autoboot: 0 >>> => bootm 01000000 >>> ## Booting kernel from Legacy Image at 01000000 ... >>> Image Name: Linux-5.15.0-rc6-dirty >>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>> Data Size: 3326878 Bytes = 3.2 MiB >>> Load Address: 00700000 >>> Entry Point: 00701aa8 >>> Verifying Checksum ... OK >>> Uncompressing Kernel Image ... OK >>> Memory <- <0x0 0x8000000> (128MB) >>> CPU clock-frequency <- 0x0 (0MHz) >>> CPU timebase-frequency <- 0x0 (0MHz) >>> /plb: clock-frequency <- 0 (0MHz) >>> /plb/opb: clock-frequency <- 0 (0MHz) >>> /plb/ebc: clock-frequency <- 0 (0MHz) >>> /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz) >>> /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz) >>> ethernet0: local-mac-address <- 00:00:00:00:00:00 >>> ethernet1: local-mac-address <- 00:00:2d:e5:44:80 >>> Fixing devtree for 4M Flash >>> >>> zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0) >>> Decompression error: 'Not a gzip file' >>> No valid compressed data found, assume uncompressed data >>> Allocating 0x6c128c bytes for kernel... >>> 0x69e1ec bytes of uncompressed data copied >>> >>> Linux/PowerPC load: >>> Finalizing device tree... flat tree at 0xdc5960 >>> Linux version 5.15.0-rc6-dirty (legoater@yukon) >>> (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross >>> 11.2.1-1), GNU ld version 2.35.2-1.fc34) #1 Tue Oct 19 15:15:21 CEST >>> 2021 >>> Using PowerPC 40x Platform machine description >>> printk: bootconsole [udbg0] enabled >>> ----------------------------------------------------- >>> phys_mem_size = 0x8000000 >>> dcache_bsize = 0x20 >>> icache_bsize = 0x20 >>> cpu_features = 0x0000000000000100 >>> possible = 0x0000000000000100 >>> always = 0x0000000000000100 >>> cpu_user_features = 0x86000000 0x00000000 >>> mmu_features = 0x00000004 >>> ----------------------------------------------------- >>> Zone ranges: >>> Normal [mem 0x0000000000000000-0x0000000007ffffff] >>> Movable zone start for each node >>> Early memory node ranges >>> node 0: [mem 0x0000000000000000-0x0000000007ffffff] >>> Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] >>> MMU: Allocated 1088 bytes of context maps for 255 contexts >>> Built 1 zonelists, mobility grouping on. Total pages: 32512 >>> Kernel command line: >>> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) >>> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) >>> mem auto-init: stack:off, heap alloc:off, heap free:off >>> Kernel virtual memory layout: >>> * 0xffbdf000..0xfffff000 : fixmap >>> * 0xc9000000..0xffbdf000 : vmalloc & ioremap >>> Memory: 122948K/131072K available (5040K kernel code, 220K rwdata, >>> 1320K rodata, 200K init, 136K bss, 8124K reserved, 0K cma-reserved) >>> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 >>> NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 >>> UIC0 (32 IRQ sources) at DCR 0xc0 >>> random: get_random_u32 called from start_kernel+0x498/0x5f8 with >>> crng_init=0 >>> >> >> Great. >> >> (gdb) bt >> #0 __div64_32 () at arch/powerpc/lib/div64.S:29 >> #1 0xc00099bc in div128_by_32 (dividend_high=<optimized out>, >> dividend_low=<optimized out>, divisor=<optimized out>, >> dr=dr@entry=0xc0693f78) at arch/powerpc/kernel/time.c:1038 >> #2 0xc0641060 in time_init () at arch/powerpc/kernel/time.c:978 >> #3 0xc063dc48 in start_kernel () at init/main.c:1055 >> #4 0xc0002204 in start_here () at arch/powerpc/kernel/head_40x.S:617 >> >> >> Looping forever in __div64_32() due to: >> >> > CPU clock-frequency <- 0x0 (0MHz) >> > CPU timebase-frequency <- 0x0 (0MHz) >> > /plb: clock-frequency <- 0 (0MHz) >> > /plb/opb: clock-frequency <- 0 (0MHz) >> > /plb/ebc: clock-frequency <- 0 (0MHz) >> > /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz) >> > /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz) > > > I dont understand how > > static bd_t bd; > > can be updated in the kernel. > It's not updated in the kernel. It is supposed to be provided by UBoot to Linux Kernel. But modern kernels don't take that anymore, they take a device tree. For this reason cuboot takes the content of bd to build/update the device tree. Looks like QEMU also provides the bd, see ref405ep_init() I managed to get a kernel booting with the following change (and with CONFIG_ETHERNET removed) diff --git a/arch/powerpc/boot/cuboot-hotfoot.c b/arch/powerpc/boot/cuboot-hotfoot.c index 888a6b9bfead..63a9545ff55d 100644 --- a/arch/powerpc/boot/cuboot-hotfoot.c +++ b/arch/powerpc/boot/cuboot-hotfoot.c @@ -132,6 +132,12 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5, unsigned long r6, unsigned long r7) { CUBOOT_INIT(); + bd.bi_intfreq = 133333333; + bd.bi_busfreq = 33333333; + bd.bi_procfreq = 133333333; + bd.bi_plb_busfreq = 33333333; + bd.bi_pci_busfreq = 33333333; + bd.bi_opbfreq = 33333333; platform_ops.fixups = hotfoot_fixups; platform_ops.exit = ibm40x_dbcr_reset; fdt_init(_dtb_start); Christophe
On 20/10/2021 14.43, Cédric Le Goater wrote: > 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. FWIW, seems like this tarball contains a dts for a "taihushui" 405ep board: https://dev.archive.openwrt.org/raw-attachment/ticket/4153/kolsch.tranzeo.openwrt.bsp.tar.bz2 ... I wonder whether that's the same board as the "taihu" board in QEMU? Thomas
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
On Wed, 20 Oct 2021, LEROY Christophe wrote: > Le 20/10/2021 à 12:10, Cédric Le Goater a écrit : >> I dont understand how >> >> static bd_t bd; >> >> can be updated in the kernel. >> > > It's not updated in the kernel. > > It is supposed to be provided by UBoot to Linux Kernel. But modern > kernels don't take that anymore, they take a device tree. For this > reason cuboot takes the content of bd to build/update the device tree. > > Looks like QEMU also provides the bd, see ref405ep_init() > > I managed to get a kernel booting with the following change (and with > CONFIG_ETHERNET removed) > > diff --git a/arch/powerpc/boot/cuboot-hotfoot.c > b/arch/powerpc/boot/cuboot-hotfoot.c > index 888a6b9bfead..63a9545ff55d 100644 > --- a/arch/powerpc/boot/cuboot-hotfoot.c > +++ b/arch/powerpc/boot/cuboot-hotfoot.c > @@ -132,6 +132,12 @@ void platform_init(unsigned long r3, unsigned long > r4, unsigned long r5, > unsigned long r6, unsigned long r7) > { > CUBOOT_INIT(); > + bd.bi_intfreq = 133333333; > + bd.bi_busfreq = 33333333; > + bd.bi_procfreq = 133333333; > + bd.bi_plb_busfreq = 33333333; > + bd.bi_pci_busfreq = 33333333; > + bd.bi_opbfreq = 33333333; > platform_ops.fixups = hotfoot_fixups; > platform_ops.exit = ibm40x_dbcr_reset; > fdt_init(_dtb_start); So maybe taihu should also provide this boot info when linux_boot is true (i.e. using -kernel) like the ref405ep does? Usually when using -kernel without -bios then QEMU has to also emulate enough of what the firmware would otherwise do like setting up devices and setting boot environment. Or if we have both -bios and -kernel then maybe -kernel should tell the firmware to boot a kernel but that may need a way to do that like setting variables in nvram but we don't have models of that in taihu. This taihu machine seems to be an early skeleton that wasn't finished, the ref405ep seems to be more advanced. Regards, BALATON Zoltan
On 20/10/2021 16.31, BALATON Zoltan wrote: > On Wed, 20 Oct 2021, LEROY Christophe wrote: >> Le 20/10/2021 à 12:10, Cédric Le Goater a écrit : >>> I dont understand how >>> >>> static bd_t bd; >>> >>> can be updated in the kernel. >>> >> >> It's not updated in the kernel. >> >> It is supposed to be provided by UBoot to Linux Kernel. But modern >> kernels don't take that anymore, they take a device tree. For this >> reason cuboot takes the content of bd to build/update the device tree. >> >> Looks like QEMU also provides the bd, see ref405ep_init() >> >> I managed to get a kernel booting with the following change (and with >> CONFIG_ETHERNET removed) >> >> diff --git a/arch/powerpc/boot/cuboot-hotfoot.c >> b/arch/powerpc/boot/cuboot-hotfoot.c >> index 888a6b9bfead..63a9545ff55d 100644 >> --- a/arch/powerpc/boot/cuboot-hotfoot.c >> +++ b/arch/powerpc/boot/cuboot-hotfoot.c >> @@ -132,6 +132,12 @@ void platform_init(unsigned long r3, unsigned long >> r4, unsigned long r5, >> unsigned long r6, unsigned long r7) >> { >> CUBOOT_INIT(); >> + bd.bi_intfreq = 133333333; >> + bd.bi_busfreq = 33333333; >> + bd.bi_procfreq = 133333333; >> + bd.bi_plb_busfreq = 33333333; >> + bd.bi_pci_busfreq = 33333333; >> + bd.bi_opbfreq = 33333333; >> platform_ops.fixups = hotfoot_fixups; >> platform_ops.exit = ibm40x_dbcr_reset; >> fdt_init(_dtb_start); > > So maybe taihu should also provide this boot info when linux_boot is true > (i.e. using -kernel) like the ref405ep does? Usually when using -kernel > without -bios then QEMU has to also emulate enough of what the firmware > would otherwise do like setting up devices and setting boot environment. Or > if we have both -bios and -kernel then maybe -kernel should tell the > firmware to boot a kernel but that may need a way to do that like setting > variables in nvram but we don't have models of that in taihu. This taihu > machine seems to be an early skeleton that wasn't finished, the ref405ep > seems to be more advanced. I agree, looking code, the ref405ep board seems to be in a better shape than the taihu board. My u-boot image seems to run fine with both machines, so I'd suggest that we deprecate (and later remove) the taihu board, and keep the ref405ep board in QEMU if it is still helpful for Christophe (or anybody else). Thomas
On 10/20/21 15:27, LEROY Christophe wrote: > > > Le 20/10/2021 à 12:10, Cédric Le Goater a écrit : >> On 10/20/21 11:02, Christophe Leroy wrote: >>> >>> >>> Le 19/10/2021 à 23:30, Cédric Le Goater a écrit : >>>> On 10/19/21 18:12, Christophe Leroy wrote: >>>>> >>>>> >>>>> Le 19/10/2021 à 16:56, BALATON Zoltan a écrit : >>>>>> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>>>>>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit : >>>>>>>> There is something: >>>>>>>> >>>>>>>> => bootm 0 >>>>>>>> Wrong Image Format for bootm command >>>>>>>> ERROR: can't get kernel image! >>>>>>>> >>>>>>>> => md 0 >>>>>>>> 00000000: 00000000 b497aae1 616e9207 003227a4 '..V....an...2'. >>>>>>>> 00000010: 00000000 00000000 ee36255f 05070201 .........6%_.... >>>>>>>> 00000020: 4c696e75 782d352e 31352e30 2d726335 Linux-5.15.0-rc5 >>>>>>>> 00000030: 2d303232 32342d67 61336330 30376164 -02224-ga3c007ad >>>>>>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7 ...........\.p.. >>>>>>>> >>>>>>>> => mw.l 0 0x27051956 >>>>>>>> >>>>>>>> => bootm 0 >>>>>>>> ## Booting kernel from Legacy Image at 00000000 ... >>>>>>>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>>>>>>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>>>>>>> Data Size: 3286948 Bytes = 3.1 MiB >>>>>>>> Load Address: 00000000 >>>>>>>> Entry Point: 00000000 >>>>>>>> Verifying Checksum ... Bad Data CRC >>>>>>>> ERROR: can't get kernel image! >>>>>>>> >>>>>>>> >>>>>>>> So we have something but it seems it gets overwritten by stuff. >>>>>>>> >>>>>>>> Anyway loading a uImage at 0 is just bad because it is a gzipped >>>>>>>> image that should get gunzipped at address 0. >>>>>>>> >>>>>>>> Or should we just copy the raw kernel at 0 and jump to the entry >>>>>>>> point ? But then we also need a device tree somewhere. >>>>>>>> >>>>>>> >>>>>>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that >>>>>>> address, and it seems it properly decompress the kernel: >>>>>>> >>>>>>> => bootm 0x1000000 >>>>>>> ## Booting kernel from Legacy Image at 01000000 ... >>>>>>> Image Name: Linux-5.15.0-rc5-02224-ga3c007ad >>>>>>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>>>>>> Data Size: 3296789 Bytes = 3.1 MiB >>>>>>> Load Address: 00000000 >>>>>>> Entry Point: 00000000 >>>>>>> Verifying Checksum ... OK >>>>>>> Uncompressing Kernel Image ... OK >>>>>>> >>>>>>> >>>>>>> And it initialises the MMU properly. >>>>>>> >>>>>>> Then it gets stuck because there is no devicetree. >>>>>>> >>>>>>> (gdb) bt >>>>>>> #0 0xc00094cc in udelay () >>>>>>> #1 0xc0025d34 in panic () >>>>>>> #2 0xc06415a0 in early_init_devtree () >>>>>>> #3 0xc0641da8 in machine_init () >>>>>>> #4 0xc0002200 in start_here () >>>>>> >>>>>> Maybe you need to embed a dtb in your kernel if that's possible >>>>>> somehow? Or QEMU has a -dtb option that sets machine->dtb but you >>>>>> need board code to do something with it. See how it's done in other >>>>>> boards like virtex_ml507 and sam460ex. But maybe you'd be better >>>>>> off not using -kernel option as it seems to not really working for >>>>>> these 405 boards but load and start the kernel from u-boot. Not >>>>>> sure what device does u-boot support but QEMU can emulate >>>>>> usb-storage, network, different disks so something might work with >>>>>> u-boot if this board has any peripherals. If it doesn't emulate any >>>>>> peripherals what do you expect to do with the kernel once it boots? >>>>>> >>>>> >>>>> I should be able to build a multi-FIT image that embeds the kernel >>>>> and the device tree. >>>>> >>>>> I don't know about the peripherals, what I need it a kernel that is >>>>> able to boot and run some user exe. I'm working on low level >>>>> functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace >>>>> protection, etc ... I want to be able to check that after some >>>>> modifications the kernel can still boot on every CPU sub-family, and >>>>> I need to run LKDTM tests. >>>>> >>>>> For this a kernel + initrd is enough. >>>> >>>> hotfoot.dts is the only DT with a CPU model "PowerPC,405EP". >>>> >>>> With cuImage.hotfoot, >>>> >>>> U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200) >>>> >>>> CPU: AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128) >>>> I2C boot EEPROM disabled >>>> Internal PCI arbiter enabled >>>> 16 KiB I-Cache 16 KiB D-Cache >>>> Board: Taihu - AMCC PPC405EP Evaluation Board >>>> I2C: ready >>>> DRAM: 128 MiB >>>> Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB >>>> ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB >>>> 0 Bytes >>>> *** Warning - bad CRC, using default environment >>>> >>>> PCI: Bus Dev VenId DevId Class Int >>>> PCI: >>>> Net: No ethernet found. >>>> >>>> Type run flash_nfs to mount root filesystem over NFS >>>> >>>> Hit any key to stop autoboot: 0 >>>> => bootm 01000000 >>>> ## Booting kernel from Legacy Image at 01000000 ... >>>> Image Name: Linux-5.15.0-rc6-dirty >>>> Image Type: PowerPC Linux Kernel Image (gzip compressed) >>>> Data Size: 3326878 Bytes = 3.2 MiB >>>> Load Address: 00700000 >>>> Entry Point: 00701aa8 >>>> Verifying Checksum ... OK >>>> Uncompressing Kernel Image ... OK >>>> Memory <- <0x0 0x8000000> (128MB) >>>> CPU clock-frequency <- 0x0 (0MHz) >>>> CPU timebase-frequency <- 0x0 (0MHz) >>>> /plb: clock-frequency <- 0 (0MHz) >>>> /plb/opb: clock-frequency <- 0 (0MHz) >>>> /plb/ebc: clock-frequency <- 0 (0MHz) >>>> /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz) >>>> /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz) >>>> ethernet0: local-mac-address <- 00:00:00:00:00:00 >>>> ethernet1: local-mac-address <- 00:00:2d:e5:44:80 >>>> Fixing devtree for 4M Flash >>>> >>>> zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0) >>>> Decompression error: 'Not a gzip file' >>>> No valid compressed data found, assume uncompressed data >>>> Allocating 0x6c128c bytes for kernel... >>>> 0x69e1ec bytes of uncompressed data copied >>>> >>>> Linux/PowerPC load: >>>> Finalizing device tree... flat tree at 0xdc5960 >>>> Linux version 5.15.0-rc6-dirty (legoater@yukon) >>>> (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross >>>> 11.2.1-1), GNU ld version 2.35.2-1.fc34) #1 Tue Oct 19 15:15:21 CEST >>>> 2021 >>>> Using PowerPC 40x Platform machine description >>>> printk: bootconsole [udbg0] enabled >>>> ----------------------------------------------------- >>>> phys_mem_size = 0x8000000 >>>> dcache_bsize = 0x20 >>>> icache_bsize = 0x20 >>>> cpu_features = 0x0000000000000100 >>>> possible = 0x0000000000000100 >>>> always = 0x0000000000000100 >>>> cpu_user_features = 0x86000000 0x00000000 >>>> mmu_features = 0x00000004 >>>> ----------------------------------------------------- >>>> Zone ranges: >>>> Normal [mem 0x0000000000000000-0x0000000007ffffff] >>>> Movable zone start for each node >>>> Early memory node ranges >>>> node 0: [mem 0x0000000000000000-0x0000000007ffffff] >>>> Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] >>>> MMU: Allocated 1088 bytes of context maps for 255 contexts >>>> Built 1 zonelists, mobility grouping on. Total pages: 32512 >>>> Kernel command line: >>>> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) >>>> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) >>>> mem auto-init: stack:off, heap alloc:off, heap free:off >>>> Kernel virtual memory layout: >>>> * 0xffbdf000..0xfffff000 : fixmap >>>> * 0xc9000000..0xffbdf000 : vmalloc & ioremap >>>> Memory: 122948K/131072K available (5040K kernel code, 220K rwdata, >>>> 1320K rodata, 200K init, 136K bss, 8124K reserved, 0K cma-reserved) >>>> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 >>>> NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 >>>> UIC0 (32 IRQ sources) at DCR 0xc0 >>>> random: get_random_u32 called from start_kernel+0x498/0x5f8 with >>>> crng_init=0 >>>> >>> >>> Great. >>> >>> (gdb) bt >>> #0 __div64_32 () at arch/powerpc/lib/div64.S:29 >>> #1 0xc00099bc in div128_by_32 (dividend_high=<optimized out>, >>> dividend_low=<optimized out>, divisor=<optimized out>, >>> dr=dr@entry=0xc0693f78) at arch/powerpc/kernel/time.c:1038 >>> #2 0xc0641060 in time_init () at arch/powerpc/kernel/time.c:978 >>> #3 0xc063dc48 in start_kernel () at init/main.c:1055 >>> #4 0xc0002204 in start_here () at arch/powerpc/kernel/head_40x.S:617 >>> >>> >>> Looping forever in __div64_32() due to: >>> >>> > CPU clock-frequency <- 0x0 (0MHz) >>> > CPU timebase-frequency <- 0x0 (0MHz) >>> > /plb: clock-frequency <- 0 (0MHz) >>> > /plb/opb: clock-frequency <- 0 (0MHz) >>> > /plb/ebc: clock-frequency <- 0 (0MHz) >>> > /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz) >>> > /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz) >> >> >> I dont understand how >> >> static bd_t bd; >> >> can be updated in the kernel. >> > > It's not updated in the kernel. > > It is supposed to be provided by UBoot to Linux Kernel. But modern > kernels don't take that anymore, they take a device tree. For this > reason cuboot takes the content of bd to build/update the device tree. > > Looks like QEMU also provides the bd, see ref405ep_init() yes. It is updated here : /* We put the bd structure at the top of memory */ if (bd->bi_memsize >= 0x01000000UL) bdloc = 0x01000000UL - sizeof(struct ppc4xx_bd_info_t); else bdloc = bd->bi_memsize - sizeof(struct ppc4xx_bd_info_t); then env->gpr[3] = bdloc; The structure definitions are probably out of sync :/ > > I managed to get a kernel booting with the following change (and with > CONFIG_ETHERNET removed) Looks good. Do you have a compatible builroot image ? Thanks C. > > diff --git a/arch/powerpc/boot/cuboot-hotfoot.c > b/arch/powerpc/boot/cuboot-hotfoot.c > index 888a6b9bfead..63a9545ff55d 100644 > --- a/arch/powerpc/boot/cuboot-hotfoot.c > +++ b/arch/powerpc/boot/cuboot-hotfoot.c > @@ -132,6 +132,12 @@ void platform_init(unsigned long r3, unsigned long > r4, unsigned long r5, > unsigned long r6, unsigned long r7) > { > CUBOOT_INIT(); > + bd.bi_intfreq = 133333333; > + bd.bi_busfreq = 33333333; > + bd.bi_procfreq = 133333333; > + bd.bi_plb_busfreq = 33333333; > + bd.bi_pci_busfreq = 33333333; > + bd.bi_opbfreq = 33333333; > platform_ops.fixups = hotfoot_fixups; > platform_ops.exit = ibm40x_dbcr_reset; > fdt_init(_dtb_start); > > > Christophe >
On 10/20/21 16:34, Thomas Huth wrote: > On 20/10/2021 16.31, BALATON Zoltan wrote: >> On Wed, 20 Oct 2021, LEROY Christophe wrote: >>> Le 20/10/2021 à 12:10, Cédric Le Goater a écrit : >>>> I dont understand how >>>> >>>> static bd_t bd; >>>> >>>> can be updated in the kernel. >>>> >>> >>> It's not updated in the kernel. >>> >>> It is supposed to be provided by UBoot to Linux Kernel. But modern >>> kernels don't take that anymore, they take a device tree. For this >>> reason cuboot takes the content of bd to build/update the device tree. >>> >>> Looks like QEMU also provides the bd, see ref405ep_init() >>> >>> I managed to get a kernel booting with the following change (and with >>> CONFIG_ETHERNET removed) >>> >>> diff --git a/arch/powerpc/boot/cuboot-hotfoot.c >>> b/arch/powerpc/boot/cuboot-hotfoot.c >>> index 888a6b9bfead..63a9545ff55d 100644 >>> --- a/arch/powerpc/boot/cuboot-hotfoot.c >>> +++ b/arch/powerpc/boot/cuboot-hotfoot.c >>> @@ -132,6 +132,12 @@ void platform_init(unsigned long r3, unsigned long >>> r4, unsigned long r5, >>> unsigned long r6, unsigned long r7) >>> { >>> CUBOOT_INIT(); >>> + bd.bi_intfreq = 133333333; >>> + bd.bi_busfreq = 33333333; >>> + bd.bi_procfreq = 133333333; >>> + bd.bi_plb_busfreq = 33333333; >>> + bd.bi_pci_busfreq = 33333333; >>> + bd.bi_opbfreq = 33333333; >>> platform_ops.fixups = hotfoot_fixups; >>> platform_ops.exit = ibm40x_dbcr_reset; >>> fdt_init(_dtb_start); >> >> So maybe taihu should also provide this boot info when linux_boot is true (i.e. using -kernel) like the ref405ep does? Usually when using -kernel without -bios then QEMU has to also emulate enough of what the firmware would otherwise do like setting up devices and setting boot environment. Or if we have both -bios and -kernel then maybe -kernel should tell the firmware to boot a kernel but that may need a way to do that like setting variables in nvram but we don't have models of that in taihu. This taihu machine seems to be an early skeleton that wasn't finished, the ref405ep seems to be more advanced. > > I agree, looking code, the ref405ep board seems to be in a better shape than the taihu board. My u-boot image seems to run fine with both machines, so I'd suggest that we deprecate (and later remove) the taihu board, and keep the ref405ep board in QEMU if it is still helpful for Christophe (or anybody else). Yes. It could nearly run userspace, if one was available. Thanks, C. U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200) CPU: AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128) I2C boot EEPROM disabled Internal PCI arbiter enabled 16 KiB I-Cache 16 KiB D-Cache Board: Taihu - AMCC PPC405EP Evaluation Board I2C: ready DRAM: 128 MiB Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB 0 Bytes *** Warning - bad CRC, using default environment PCI: Bus Dev VenId DevId Class Int PCI: Net: No ethernet found. Type run flash_nfs to mount root filesystem over NFS Hit any key to stop autoboot: 0 => bootm 0x1000000 ## Booting kernel from Legacy Image at 01000000 ... Image Name: Linux-5.15.0-rc6-dirty Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 3870579 Bytes = 3.7 MiB Load Address: 00800000 Entry Point: 00801ad0 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory <- <0x0 0x8000000> (128MB) CPU clock-frequency <- 0x7f28155 (133MHz) CPU timebase-frequency <- 0x7f28155 (133MHz) /plb: clock-frequency <- 1fca055 (33MHz) /plb/opb: clock-frequency <- 1fca055 (33MHz) /plb/ebc: clock-frequency <- 1fca055 (33MHz) /plb/opb/serial@ef600300: clock-frequency <- 1d1079 (2MHz) /plb/opb/serial@ef600400: clock-frequency <- 1d1079 (2MHz) ethernet0: local-mac-address <- 00:00:00:00:00:00 ethernet1: local-mac-address <- 00:00:2d:e5:44:80 Fixing devtree for 4M Flash zImage starting: loaded at 0x00800000 (sp: 0x07eaabb0) Decompression error: 'Not a gzip file' No valid compressed data found, assume uncompressed data Allocating 0x73f274 bytes for kernel... 0x71c0f0 bytes of uncompressed data copied Linux/PowerPC load: Finalizing device tree... flat tree at 0xf43960 Linux version 5.15.0-rc6-dirty (legoater@yukon) (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1), GNU ld version 2.35.2-1.fc34) #4 Wed Oct 20 16:37:46 CEST 2021 Using PowerPC 40x Platform machine description printk: bootconsole [udbg0] enabled ----------------------------------------------------- phys_mem_size = 0x8000000 dcache_bsize = 0x20 icache_bsize = 0x20 cpu_features = 0x0000000000000100 possible = 0x0000000000000100 always = 0x0000000000000100 cpu_user_features = 0x86000000 0x00000000 mmu_features = 0x00000004 ----------------------------------------------------- Zone ranges: Normal [mem 0x0000000000000000-0x0000000007ffffff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000000000000-0x0000000007ffffff] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists, mobility grouping on. Total pages: 32512 Kernel command line: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) mem auto-init: stack:off, heap alloc:off, heap free:off Kernel virtual memory layout: * 0xffbdf000..0xfffff000 : fixmap * 0xc9000000..0xffbdf000 : vmalloc & ioremap Memory: 122444K/131072K available (4908K kernel code, 224K rwdata, 1300K rodata, 852K init, 136K bss, 8628K reserved, 0K cma-reserved) SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 UIC0 (32 IRQ sources) at DCR 0xc0 random: get_random_u32 called from start_kernel+0x498/0x5f8 with crng_init=0 clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x1ec031343f, max_idle_ns: 440795203544 ns clocksource: timebase mult[7800000] shift[24] registered pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns futex hash table entries: 256 (order: -1, 3072 bytes, linear) NET: Registered PF_NETLINK/PF_ROUTE protocol family DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations thermal_sys: Registered thermal governor 'step_wise' PCI host bridge /plb/pci@ec000000 (primary) ranges: MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000 IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000 4xx PCI DMA offset set to 0x00000000 4xx PCI DMA window base to 0x0000000000000000 DMA window size 0x0000000080000000 PCI: Probing PCI hardware PCI host bridge to bus 0008:00 pci_bus 0008:00: root bus resource [io 0x0000-0xffff] pci_bus 0008:00: root bus resource [mem 0x80000000-0x9fffffff] pci_bus 0008:00: root bus resource [bus 00-ff] pci_bus 0008:00: busn_res: [bus 00-ff] end is updated to ff pci_bus 0008:00: busn_res: [bus 00-ff] end is updated to 00 pci_bus 0008:00: resource 4 [io 0x0000-0xffff] pci_bus 0008:00: resource 5 [mem 0x80000000-0x9fffffff] vgaarb: loaded pps_core: LinuxPPS API ver. 1 registered pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> PTP clock support registered clocksource: Switched to clocksource timebase NET: Registered PF_INET protocol family IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear) tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear) TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear) TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear) TCP: Hash tables configured (established 1024 bind 1024) UDP hash table entries: 256 (order: 0, 4096 bytes, linear) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear) NET: Registered PF_UNIX/PF_LOCAL protocol family RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. PCI: CLS 0 bytes, default 32 workingset: timestamp_bits=30 max_order=15 bucket_order=0 io scheduler mq-deadline registered io scheduler kyber registered Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled printk: console [ttyS0] disabled serial8250.0: ttyS0 at MMIO 0xef600400 (irq = 16, base_baud = 119047) is a 16550A printk: console [ttyS0] enabled printk: console [ttyS0] enabled printk: bootconsole [udbg0] disabled printk: bootconsole [udbg0] disabled serial8250.0: ttyS1 at MMIO 0xef600300 (irq = 17, base_baud = 119047) is a 16550A printk: console [ttyS0] disabled printk: console [ttyS0] enabled ef600300.serial: ttyS1 at MMIO 0xef600300 (irq = 17, base_baud = 119047) is a 16550 brd: module loaded libphy: Fixed MDIO Bus: probed NET: Registered PF_INET6 protocol family Segment Routing with IPv6 In-situ OAM (IOAM) with IPv6 sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver NET: Registered PF_PACKET protocol family drmem: No dynamic reconfiguration memory found Freeing unused kernel image (initmem) memory: 852K Kernel memory protection not selected by kernel config. Run /init as init process init[1]: illegal instruction (4) at 10038380 nip 10038380 lr 10034be0 code 1 in busybox[10000000+61000] init[1]: code: 6129c000 7f914840 419d0350 562be13e 380bffff 2b800020 409d0314 3d204330 init[1]: code: 6c008000 91210018 3d201006 9001001c <c1a9b834> c8010018 fc006828 fc000018 Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 CPU: 0 PID: 1 Comm: init Not tainted 5.15.0-rc6-dirty #4 Call Trace: [c0815da0] [c0024408] panic+0x11c/0x2e0 (unreliable) [c0815e00] [c0026038] do_exit+0x8b0/0x908 [c0815e50] [c0027044] do_group_exit+0x34/0x9c [c0815e70] [c0033bd0] get_signal+0x174/0x734 [c0815ec0] [c0007794] do_notify_resume+0x70/0x2b0 [c0815f20] [c000ca7c] interrupt_exit_user_prepare_main+0x6c/0xe0 [c0815f40] [c000f1e0] interrupt_return+0x14/0x148 --- interrupt: 700 at 0x10038380 NIP: 10038380 LR: 10034be0 CTR: 1000db60 REGS: c0815f50 TRAP: 0700 Not tainted (5.15.0-rc6-dirty) MSR: 0008c030 <EE,PR,IR,DR> CR: 40000024 XER: 00000000 GPR00: 8000005a bf9c7d90 100791f8 000005a4 bf9c8144 0000001f 00000001 1000026c GPR08: 0000c030 10060000 00001000 0000005b 72656773 00000000 00000000 00000000 GPR16: 00000000 000005b0 00000000 100726ec 00000000 00000000 00000000 00000000 GPR24: 00000000 00000002 00000002 bf9c8144 10070000 000005a4 bf9c8144 000005a4 NIP [10038380] 0x10038380 LR [10034be0] 0x10034be0 --- interrupt: 700 Rebooting in 180 seconds.. QEMU 6.1.50 monitor - type 'help' for more information
On Wed, 20 Oct 2021, Thomas Huth wrote: > On 20/10/2021 14.43, Cédric Le Goater wrote: > >> 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. > > FWIW, seems like this tarball contains a dts for a "taihushui" 405ep board: > > https://dev.archive.openwrt.org/raw-attachment/ticket/4153/kolsch.tranzeo.openwrt.bsp.tar.bz2 > > ... I wonder whether that's the same board as the "taihu" board in QEMU? The corresponding ticket has some info on the machine: https://dev.archive.openwrt.org/ticket/4153.html but it's not clear what taihu in QEMU is in the first place. The comment in ppc405_boards.c says it's an evaluation board so most likely the above one may have been designed based on this reference board. Some info on the eval board can be found here: http://www.welcm.com/amccTaihu/amccTaihu.htm https://datasheet.octopart.com/EV-460GT-KIT-03-AMCC-datasheet-11746697.pdf https://happytrees.org/files/chips/datasheets/product_selector_guide--AMCC--PowerPC.pdf I wonder what ref405ep was then, an earlier or later or different version? Regards, BALATON Zoltan
Le 20/10/2021 à 16:41, Cédric Le Goater a écrit : > init[1]: illegal instruction (4) at 10038380 nip 10038380 lr 10034be0 > code 1 in busybox[10000000+61000] > init[1]: code: 6129c000 7f914840 419d0350 562be13e 380bffff 2b800020 > 409d0314 3d204330 > init[1]: code: 6c008000 91210018 3d201006 9001001c <c1a9b834> c8010018 > fc006828 fc000018 That's a floating point instruction. You need CONFIG_MATH_EMULATION. > Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 > CPU: 0 PID: 1 Comm: init Not tainted 5.15.0-rc6-dirty #4 > Call Trace: > [c0815da0] [c0024408] panic+0x11c/0x2e0 (unreliable) > [c0815e00] [c0026038] do_exit+0x8b0/0x908 > [c0815e50] [c0027044] do_group_exit+0x34/0x9c > [c0815e70] [c0033bd0] get_signal+0x174/0x734 > [c0815ec0] [c0007794] do_notify_resume+0x70/0x2b0 > [c0815f20] [c000ca7c] interrupt_exit_user_prepare_main+0x6c/0xe0 > [c0815f40] [c000f1e0] interrupt_return+0x14/0x148 > --- interrupt: 700 at 0x10038380 > NIP: 10038380 LR: 10034be0 CTR: 1000db60 > REGS: c0815f50 TRAP: 0700 Not tainted (5.15.0-rc6-dirty) > MSR: 0008c030 <EE,PR,IR,DR> CR: 40000024 XER: 00000000 > > GPR00: 8000005a bf9c7d90 100791f8 000005a4 bf9c8144 0000001f 00000001 > 1000026c > GPR08: 0000c030 10060000 00001000 0000005b 72656773 00000000 00000000 > 00000000 > GPR16: 00000000 000005b0 00000000 100726ec 00000000 00000000 00000000 > 00000000 > GPR24: 00000000 00000002 00000002 bf9c8144 10070000 000005a4 bf9c8144 > 000005a4 > NIP [10038380] 0x10038380 > LR [10034be0] 0x10034be0 > --- interrupt: 700 > Rebooting in 180 seconds.. > QEMU 6.1.50 monitor - type 'help' for more information
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
On 20/10/2021 16.55, BALATON Zoltan wrote: > On Wed, 20 Oct 2021, Thomas Huth wrote: >> On 20/10/2021 14.43, Cédric Le Goater wrote: >> >>> 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. >> >> FWIW, seems like this tarball contains a dts for a "taihushui" 405ep board: >> >> https://dev.archive.openwrt.org/raw-attachment/ticket/4153/kolsch.tranzeo.openwrt.bsp.tar.bz2 >> >> >> ... I wonder whether that's the same board as the "taihu" board in QEMU? > > The corresponding ticket has some info on the machine: > > https://dev.archive.openwrt.org/ticket/4153.html Ok, so as far as I got that now, Taihu was a board by AMCC, while Taihushui was from Tranzeo ? ... so they were likely different boards, I think. > I wonder what ref405ep was then, an earlier or later or different version? According to hw/ppc/ppc405_boards.c, the ref405ep machine was a reference board by IBM, not from AMCC ? Thomas
Le 20/10/2021 à 16:39, Cédric Le Goater a écrit : > On 10/20/21 15:27, LEROY Christophe wrote: >> I managed to get a kernel booting with the following change (and with >> CONFIG_ETHERNET removed) > > Looks good. > > Do you have a compatible builroot image ? > I'm trying with the cpio one from https://github.com/groeck/linux-build-test/tree/master/rootfs/ppc Christophe
Le 20/10/2021 à 15:16, Christophe Leroy a écrit : > > > 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. I bisected the issue to https://github.com/linuxppc/linux/commit/52ae92cc290f0506eef9ad5466bb453ce4a9e80e The problem is in QEMU, it should ignore upper bits of PID register. The following change fixes the issue, don't know it is it the right way to fix though diff --git a/target/ppc/mmu_common.c b/target/ppc/mmu_common.c index 754509e556..44f4fa5280 100644 --- a/target/ppc/mmu_common.c +++ b/target/ppc/mmu_common.c @@ -570,7 +570,7 @@ static int mmu40x_get_physical_address(CPUPPCState *env, mmu_ctx_t *ctx, for (i = 0; i < env->nb_tlb; i++) { tlb = &env->tlb.tlbe[i]; if (ppcemb_tlb_check(env, tlb, &raddr, address, - env->spr[SPR_40x_PID], 0, i) < 0) { + env->spr[SPR_40x_PID] & 0xff, 0, i) < 0) { continue; } zsel = (tlb->attr >> 4) & 0xF; diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c index 2cb98c5169..9331830f34 100644 --- a/target/ppc/mmu_helper.c +++ b/target/ppc/mmu_helper.c @@ -789,7 +789,7 @@ void helper_4xx_tlbwe_hi(CPUPPCState *env, target_ulong entry, } else { tlb->prot &= ~PAGE_VALID; } - tlb->PID = env->spr[SPR_40x_PID]; /* PID */ + tlb->PID = env->spr[SPR_40x_PID] & 0xff; /* PID */ LOG_SWTLB("%s: set up TLB %d RPN " TARGET_FMT_plx " EPN " TARGET_FMT_lx " size " TARGET_FMT_lx " prot %c%c%c%c PID %d\n", __func__, (int)entry, tlb->RPN, tlb->EPN, tlb->size, @@ -837,7 +837,7 @@ void helper_4xx_tlbwe_lo(CPUPPCState *env, target_ulong entry, target_ulong helper_4xx_tlbsx(CPUPPCState *env, target_ulong address) { - return ppcemb_tlb_search(env, address, env->spr[SPR_40x_PID]); + return ppcemb_tlb_search(env, address, env->spr[SPR_40x_PID] & 0xff); } /* PowerPC 440 TLB management */ --- Christophe
On 21/10/2021 08.48, Christophe Leroy wrote: > > > Le 20/10/2021 à 15:16, Christophe Leroy a écrit : >> >> >> 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. > > I bisected the issue to > https://github.com/linuxppc/linux/commit/52ae92cc290f0506eef9ad5466bb453ce4a9e80e You could argue that this commit introduced a bug, or at least a bad behavior in the kernel: According to the 405 user's manual that I have: 10.2 Reserved Fields For all registers having fields marked as reserved, the reserved fields should be written as zero and read as undefined. That is, when writing to a reseved field, write a 0 to the field. When reading from a reserved field, ignore the field. Thus the kernel should not write non-zero bits into the upper bits of this register. > The problem is in QEMU, it should ignore upper bits of PID register. Agreed, that's certainly necessary, too. > The following change fixes the issue, don't know it is it the right way to > fix though > > diff --git a/target/ppc/mmu_common.c b/target/ppc/mmu_common.c > index 754509e556..44f4fa5280 100644 > --- a/target/ppc/mmu_common.c > +++ b/target/ppc/mmu_common.c > @@ -570,7 +570,7 @@ static int mmu40x_get_physical_address(CPUPPCState *env, > mmu_ctx_t *ctx, > for (i = 0; i < env->nb_tlb; i++) { > tlb = &env->tlb.tlbe[i]; > if (ppcemb_tlb_check(env, tlb, &raddr, address, > - env->spr[SPR_40x_PID], 0, i) < 0) { > + env->spr[SPR_40x_PID] & 0xff, 0, i) < 0) { > continue; > } > zsel = (tlb->attr >> 4) & 0xF; > diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c > index 2cb98c5169..9331830f34 100644 > --- a/target/ppc/mmu_helper.c > +++ b/target/ppc/mmu_helper.c > @@ -789,7 +789,7 @@ void helper_4xx_tlbwe_hi(CPUPPCState *env, target_ulong > entry, > } else { > tlb->prot &= ~PAGE_VALID; > } > - tlb->PID = env->spr[SPR_40x_PID]; /* PID */ > + tlb->PID = env->spr[SPR_40x_PID] & 0xff; /* PID */ > LOG_SWTLB("%s: set up TLB %d RPN " TARGET_FMT_plx " EPN " TARGET_FMT_lx > " size " TARGET_FMT_lx " prot %c%c%c%c PID %d\n", __func__, > (int)entry, tlb->RPN, tlb->EPN, tlb->size, > @@ -837,7 +837,7 @@ void helper_4xx_tlbwe_lo(CPUPPCState *env, target_ulong > entry, > > target_ulong helper_4xx_tlbsx(CPUPPCState *env, target_ulong address) > { > - return ppcemb_tlb_search(env, address, env->spr[SPR_40x_PID]); > + return ppcemb_tlb_search(env, address, env->spr[SPR_40x_PID] & 0xff); > } The modications looks sane to me, could you please send this as a proper patch (with Signed-off-by line) to the mailing list? Alternatively, it might be possible to do the masking only once in helper_booke_setpid() in mmu_helper.c: void helper_booke_setpid(CPUPPCState *env, uint32_t pidn, target_ulong pid) { if (pid == SPR_40x_PID) { pid &= 0xff; } env->spr[pidn] = pid; /* changing PIDs mean we're in a different address space now */ tlb_flush(env_cpu(env)); } ... not sure whether that is the better approach here, though ... it maybe depends whether the reserved bits read back as zeros on a real 405 or not... Thomas
Le 21/10/2021 à 09:25, Thomas Huth a écrit : > On 21/10/2021 08.48, Christophe Leroy wrote: >> >> >> Le 20/10/2021 à 15:16, Christophe Leroy a écrit : >>> >>> >>> 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. >> >> I bisected the issue to >> https://github.com/linuxppc/linux/commit/52ae92cc290f0506eef9ad5466bb453ce4a9e80e > > > You could argue that this commit introduced a bug, or at least a bad > behavior in the kernel: According to the 405 user's manual that I have: > > 10.2 Reserved Fields > For all registers having fields marked as reserved, the reserved > fields should be written as zero and read as undefined. That is, > when writing to a reseved field, write a 0 to the field. When > reading from a reserved field, ignore the field. > > Thus the kernel should not write non-zero bits into the upper bits of > this register. Yes, SHOULD, not SHALL ... The following changes fixes the issue in the kernel though: diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S index 618d7f3f9c95..bcde7e284bfa 100644 --- a/arch/powerpc/kernel/head_40x.S +++ b/arch/powerpc/kernel/head_40x.S @@ -317,8 +317,9 @@ _ENTRY(saved_ksp_limit) /* The bailout. Restore registers to pre-exception conditions * and call the heavyweights to help us out. */ - mtspr SPRN_PID, r12 mtcrf 0x80, r12 + rlwinm r12, r12, 0, 0xff + mtspr SPRN_PID, r12 mfspr r9, SPRN_SPRG_SCRATCH4 mfspr r12, SPRN_SPRG_SCRATCH3 mfspr r11, SPRN_SPRG_SCRATCH6 @@ -397,8 +398,9 @@ _ENTRY(saved_ksp_limit) /* The bailout. Restore registers to pre-exception conditions * and call the heavyweights to help us out. */ - mtspr SPRN_PID, r12 mtcrf 0x80, r12 + rlwinm r12, r12, 0, 0xff + mtspr SPRN_PID, r12 mfspr r9, SPRN_SPRG_SCRATCH4 mfspr r12, SPRN_SPRG_SCRATCH3 mfspr r11, SPRN_SPRG_SCRATCH6 @@ -542,8 +544,9 @@ finish_tlb_load: /* Done...restore registers and get out of here. */ - mtspr SPRN_PID, r12 mtcrf 0x80, r12 + rlwinm r12, r12, 0, 0xff + mtspr SPRN_PID, r12 mfspr r9, SPRN_SPRG_SCRATCH4 mfspr r12, SPRN_SPRG_SCRATCH3 mfspr r11, SPRN_SPRG_SCRATCH6 > >> The problem is in QEMU, it should ignore upper bits of PID register. > > Agreed, that's certainly necessary, too. Yes it seems clear in 405 user's manual chapter 7 Memory Management, especially in all drawings, that only bits 24:31 are taken into account from PID register. Christophe
On 10/5/21 18:20, Daniel P. Berrangé wrote: > On Tue, Oct 05, 2021 at 06:15:35PM +0200, Philippe Mathieu-Daudé wrote: >> On 10/5/21 10:49, Daniel P. Berrangé wrote: >>> On Tue, Oct 05, 2021 at 06:44:23AM +0200, Christophe Leroy wrote: >> >>>> I will look at it, please allow me a few weeks though. >>> >>> Once something is deprecated, it remains in QEMU for a minimum of two >>> release cycles, before being deleted. At any time in that deprecation >>> period it can be returned to supported status, if someone provides a >>> good enough justification to keep it. >> >> My understanding is once being in deprecated state for 2 releases, it >> can be removed, but it doesn't have to be removed (assuming it is >> functional and nobody complains). Am I incorrect? > > It should be removed after 2 releases. Things live longer because > people forget or are busy with other things, but ultimately anything > in the deprecated list is liable to be deleted at any point after > the 2 release minimum is up. > > If we change our minds about deleting something, then it should > be un-deprecated. Sigh. This is more work on me then. >> I am raising this because the nanoMIPS support is in deprecated state >> since more than 2 releases, but it is still in-tree and I try to keep >> it functional. However, since no toolchain reached mainstream GCC/LLVM >> it is not easy to maintain. By keeping it in that state we give some >> time to other communities to have their toolchain upstreamed / merged. > > If you're trying to keep it functional and aren't going to remove > it, then it shouldn't be marked deprecated. OK, I'll move it back to Odd-fixes.
>>> I am raising this because the nanoMIPS support is in deprecated state >>> since more than 2 releases, but it is still in-tree and I try to keep >>> it functional. However, since no toolchain reached mainstream GCC/LLVM >>> it is not easy to maintain. By keeping it in that state we give some >>> time to other communities to have their toolchain upstreamed / merged. >> >> If you're trying to keep it functional and aren't going to remove >> it, then it shouldn't be marked deprecated. > > OK, I'll move it back to Odd-fixes. The ppc405 boards are still in pretty bad shape. We need a patched u-boot, a patched QEMU and a patched Linux and still, we do not reach user space without some sort of crash. C.
Hi Cédric, Le 27/10/2021 à 10:40, Cédric Le Goater a écrit : >>>> I am raising this because the nanoMIPS support is in deprecated state >>>> since more than 2 releases, but it is still in-tree and I try to keep >>>> it functional. However, since no toolchain reached mainstream GCC/LLVM >>>> it is not easy to maintain. By keeping it in that state we give some >>>> time to other communities to have their toolchain upstreamed / merged. >>> >>> If you're trying to keep it functional and aren't going to remove >>> it, then it shouldn't be marked deprecated. >> >> OK, I'll move it back to Odd-fixes. > > The ppc405 boards are still in pretty bad shape. We need a patched u-boot, > a patched QEMU and a patched Linux and still, we do not reach user space > without some sort of crash. > I guess Philippe was talking about the nanoMIPS here. By the way, ppc405 is not on an optimal shape yet for sure, but we are getting better and better, and I'm aiming at getting it back to work, just because I need it. By the way, were you able to re-test with CONFIG_MATH_EMULATION enabled after your last oops report which shows that you're trying to execute floating points instruction ? Thanks Christophe
On 10/27/21 12:42, Christophe Leroy wrote: > Le 27/10/2021 à 10:40, Cédric Le Goater a écrit : >>>>> I am raising this because the nanoMIPS support is in deprecated state >>>>> since more than 2 releases, but it is still in-tree and I try to keep >>>>> it functional. However, since no toolchain reached mainstream GCC/LLVM >>>>> it is not easy to maintain. By keeping it in that state we give some >>>>> time to other communities to have their toolchain upstreamed / merged. >>>> >>>> If you're trying to keep it functional and aren't going to remove >>>> it, then it shouldn't be marked deprecated. >>> >>> OK, I'll move it back to Odd-fixes. >> >> The ppc405 boards are still in pretty bad shape. We need a patched >> u-boot, >> a patched QEMU and a patched Linux and still, we do not reach user space >> without some sort of crash. >> > > I guess Philippe was talking about the nanoMIPS here. Yes, I was following the deprecation thread, sorry for the confusion.
Hello Christophe, On 10/27/21 12:42, Christophe Leroy wrote: > Hi Cédric, > > Le 27/10/2021 à 10:40, Cédric Le Goater a écrit : >>>>> I am raising this because the nanoMIPS support is in deprecated state >>>>> since more than 2 releases, but it is still in-tree and I try to keep >>>>> it functional. However, since no toolchain reached mainstream GCC/LLVM >>>>> it is not easy to maintain. By keeping it in that state we give some >>>>> time to other communities to have their toolchain upstreamed / merged. >>>> >>>> If you're trying to keep it functional and aren't going to remove >>>> it, then it shouldn't be marked deprecated. >>> >>> OK, I'll move it back to Odd-fixes. >> >> The ppc405 boards are still in pretty bad shape. We need a patched u-boot, >> a patched QEMU and a patched Linux and still, we do not reach user space >> without some sort of crash. >> > > I guess Philippe was talking about the nanoMIPS here. > > By the way, ppc405 is not on an optimal shape yet for sure, but we are getting better and better, and I'm aiming at getting it back to work, just because I need it. > > By the way, were you able to re-test with CONFIG_MATH_EMULATION enabled after your last oops report which shows that you're trying to execute floating points instruction ? > That's the best I got :( Please send me your .config. Thanks, C. => bootm 0x1000000 ## Booting kernel from Legacy Image at 01000000 ... Image Name: Linux-5.15.0-rc7-dirty Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 3273457 Bytes = 3.1 MiB Load Address: 00700000 Entry Point: 00701ad0 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory <- <0x0 0x8000000> (128MB) CPU clock-frequency <- 0x7f28155 (133MHz) CPU timebase-frequency <- 0x7f28155 (133MHz) /plb: clock-frequency <- 1fca055 (33MHz) /plb/opb: clock-frequency <- 1fca055 (33MHz) /plb/ebc: clock-frequency <- 1fca055 (33MHz) /plb/opb/serial@ef600300: clock-frequency <- 1d1079 (2MHz) /plb/opb/serial@ef600400: clock-frequency <- 1d1079 (2MHz) ethernet0: local-mac-address <- 00:00:00:00:00:00 ethernet1: local-mac-address <- 00:00:2d:e5:44:80 Fixing devtree for 4M Flash zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0) Decompression error: 'Not a gzip file' No valid compressed data found, assume uncompressed data Allocating 0x6bd274 bytes for kernel... 0x69a114 bytes of uncompressed data copied Linux/PowerPC load: Finalizing device tree... flat tree at 0xdc1960 Linux version 5.15.0-rc7-dirty (legoater@yukon) (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1), GNU ld version 2.35.2-1.fc34) #14 Wed Oct 27 18:41:41 CEST 2021 Using PowerPC 40x Platform machine description printk: bootconsole [udbg0] enabled ----------------------------------------------------- phys_mem_size = 0x8000000 dcache_bsize = 0x20 icache_bsize = 0x20 cpu_features = 0x0000000000000100 possible = 0x0000000000000100 always = 0x0000000000000100 cpu_user_features = 0x86000000 0x00000000 mmu_features = 0x00000004 ----------------------------------------------------- Zone ranges: Normal [mem 0x0000000000000000-0x0000000007ffffff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000000000000-0x0000000007ffffff] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists, mobility grouping on. Total pages: 32512 Kernel command line: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) mem auto-init: stack:off, heap alloc:off, heap free:off Kernel virtual memory layout: * 0xffbdf000..0xfffff000 : fixmap * 0xc9000000..0xffbdf000 : vmalloc & ioremap Memory: 122964K/131072K available (4920K kernel code, 224K rwdata, 1304K rodata, 316K init, 136K bss, 8108K reserved, 0K cma-reserved) SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 UIC0 (32 IRQ sources) at DCR 0xc0 random: get_random_u32 called from start_kernel+0x498/0x5f8 with crng_init=0 clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x1ec031343f, max_idle_ns: 440795203544 ns clocksource: timebase mult[7800000] shift[24] registered pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns futex hash table entries: 256 (order: -1, 3072 bytes, linear) NET: Registered PF_NETLINK/PF_ROUTE protocol family DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations thermal_sys: Registered thermal governor 'step_wise' PCI host bridge /plb/pci@ec000000 (primary) ranges: MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000 IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000 4xx PCI DMA offset set to 0x00000000 4xx PCI DMA window base to 0x0000000000000000 DMA window size 0x0000000080000000 PCI: Probing PCI hardware PCI host bridge to bus 0008:00 pci_bus 0008:00: root bus resource [io 0x0000-0xffff] pci_bus 0008:00: root bus resource [mem 0x80000000-0x9fffffff] pci_bus 0008:00: root bus resource [bus 00-ff] pci_bus 0008:00: busn_res: [bus 00-ff] end is updated to ff pci_bus 0008:00: busn_res: [bus 00-ff] end is updated to 00 pci_bus 0008:00: resource 4 [io 0x0000-0xffff] pci_bus 0008:00: resource 5 [mem 0x80000000-0x9fffffff] vgaarb: loaded pps_core: LinuxPPS API ver. 1 registered pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> PTP clock support registered clocksource: Switched to clocksource timebase NET: Registered PF_INET protocol family IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear) tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear) TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear) TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear) TCP: Hash tables configured (established 1024 bind 1024) UDP hash table entries: 256 (order: 0, 4096 bytes, linear) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear) NET: Registered PF_UNIX/PF_LOCAL protocol family RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. PCI: CLS 0 bytes, default 32 Mem-Info: active_anon:0 inactive_anon:0 isolated_anon:0 active_file:0 inactive_file:0 isolated_file:0 unevictable:0 dirty:0 writeback:0 slab_reclaimable:11 slab_unreclaimable:171 mapped:0 shmem:0 pagetables:0 bounce:0 kernel_misc_reclaimable:0 free:30452 free_pcp:19 free_cma:0 Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB kernel_stack:152kB pagetables:0kB all_unreclaimable? no Normal free:121808kB min:1400kB low:1748kB high:2096kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:131072kB managed:122964kB mlocked:0kB bounce:0kB free_pcp:76kB local_pcp:76kB free_cma:0kB lowmem_reserve[]: 0 0 Normal: 4*4kB (UM) 2*8kB (ME) 3*16kB (UM) 2*32kB (UM) 3*64kB (ME) 3*128kB (UME) 5*256kB (UME) 4*512kB (UME) 3*1024kB (ME) 4*2048kB (UME) 26*4096kB (M) = 121808kB 0 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 32768 pages RAM 0 pages HighMem/MovableOnly 2027 pages reserved Kernel panic - not syncing: CPU: 0 PID: 5 Comm: kworker/u2:0 Not tainted 5.15.0-rc7-dirty #12 Workqueue: events_unbound async_run_entry_fn Call Trace: [c0845d70] [c0026a40] panic+0x11c/0x2e0 (unreliable) [c0845dd0] [c000513c] sys_mmap2+0x0/0x20 [c0845e20] [c0617844] do_populate_rootfs+0x48/0x17c [c0845e60] [c004a8ec] async_run_entry_fn+0x34/0xc4 [c0845e80] [c003f6c0] process_one_work+0x268/0x3e0 [c0845eb0] [c003fd40] worker_thread+0x17c/0x4c4 [c0845f00] [c0047898] kthread+0x12c/0x14c [c0845f40] [c0010114] ret_from_kernel_thread+0x14/0x1c Rebooting in 180 seconds..
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?
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
diff --git a/MAINTAINERS b/MAINTAINERS index f2060b46f9..1ecb5716c8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1236,24 +1236,18 @@ F: hw/openrisc/openrisc_sim.c PowerPC Machines ---------------- 405 -M: David Gibson <david@gibson.dropbear.id.au> -M: Greg Kurz <groug@kaod.org> L: qemu-ppc@nongnu.org -S: Odd Fixes +S: Orphan F: hw/ppc/ppc405_boards.c Bamboo -M: David Gibson <david@gibson.dropbear.id.au> -M: Greg Kurz <groug@kaod.org> L: qemu-ppc@nongnu.org -S: Odd Fixes +S: Orphan F: hw/ppc/ppc440_bamboo.c e500 -M: David Gibson <david@gibson.dropbear.id.au> -M: Greg Kurz <groug@kaod.org> L: qemu-ppc@nongnu.org -S: Odd Fixes +S: Orphan F: hw/ppc/e500* F: hw/gpio/mpc8xxx.c F: hw/i2c/mpc_i2c.c @@ -1264,10 +1258,8 @@ F: include/hw/pci-host/ppce500.h F: pc-bios/u-boot.e500 mpc8544ds -M: David Gibson <david@gibson.dropbear.id.au> -M: Greg Kurz <groug@kaod.org> L: qemu-ppc@nongnu.org -S: Odd Fixes +S: Orphan F: hw/ppc/mpc8544ds.c F: hw/ppc/mpc8544_guts.c F: tests/acceptance/ppc_mpc8544ds.py @@ -1777,9 +1769,8 @@ F: include/hw/acpi/ghes.h F: docs/specs/acpi_hest_ghes.rst ppc4xx -M: David Gibson <david@gibson.dropbear.id.au> L: qemu-ppc@nongnu.org -S: Odd Fixes +S: Orphan F: hw/ppc/ppc4*.c F: hw/i2c/ppc4xx_i2c.c F: include/hw/ppc/ppc4xx.h