Re: Deprecate the ppc405 boards in QEMU?

[Christophe Leroy]

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