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
