|
From: | BALATON Zoltan |
Subject: | Re: Deprecate the ppc405 boards in QEMU? |
Date: | Tue, 19 Oct 2021 14:38:02 +0200 (CEST) |
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 Iwonder where it gets that from. Maybe by reading the SDRAMcontroller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure whatit needs the SPD for, I forgot how this worked on sam460ex. Maybe for the speed calibration, so could be it detects ram by readingDCRs then tries to get SPD data and that's where it stops as i2c isnot emulated on taihu. This could be confirmed by checking what it pokes with -d guest_errors that shows accesses to missing devicesbut don't know where 405 has the i2c controller and if it's the sameas newer SoCs. If so that could be reused and an i2c bus could beadded with the SPD data like in sam460ex to make u-boot happy or youcould 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/taihuI also added a gitlab-CI file, so you can now download the u-boot.bin as anartifact from the corresponding pipeline, e.g.: https://gitlab.com/huth/u-boot/-/jobs/1667201028Thanks. 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.htmlI 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_defconfigI 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/uImageI'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 -sUboot for e500 has the following environment: => printenvbootcmd=test -n "$qemu_kernel_addr" && bootm $qemu_kernel_addr - $fdt_addr_rfdt_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 0x00000000but 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
[Prev in Thread] | Current Thread | [Next in Thread] |