Re: Deprecate the ppc405 boards in QEMU?

[Christophe Leroy]

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