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
