qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Deprecate the ppc405 boards in QEMU?


From: BALATON Zoltan
Subject: Re: Deprecate the ppc405 boards in QEMU?
Date: Wed, 20 Oct 2021 13:40:10 +0200 (CEST)

On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
On 10/19/21 13:11, Thomas Huth wrote:
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.

When using -kernel/-append, if a BIOS is required by the kernel,
then it should be crafted by the machine IMO. Usually OS only
access a configuration area in PROM. The PROM must be mapped,
and the minimum configuration structure filled.

Anyhow I find -bios confusing, I never know if this option parse
or expects a full/partial raw flash image, an ELF image, something
else...

Generally a firmware image in whatever format the board expects. Usually raw binary or ELF. Not that different from -kernel that also takes different formats depending on the machine. Think of -bios like -kernel for firmware, i.e. specifying what firmware to use like -kernel specifies what kernel to use.

Regards,
BALATON Zoltan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]