Re: [Qemu-devel] Running u-boot on raspi2

[Peter Maydell]

On Fri, 23 Aug 2019 at 16:54, Bonnans, Laurent <address@hidden> wrote:
>
> Hi,
>
> We (mostly Cheng Xiang's work) have been trying to use the raspi2
> machine to boot an image through u-boot.
> It seems, however, that there are some missing pieces:
>
> The first problem is that it trips very early if we keep the cpus count
> at 4 but will continue if we hard-patch it to be a single core.
> Symptom is that it seems all cores are running and trying to execute
> something, while u-boot probably has not intention of doing something
> with SMP.
> Our guess is that it's something related to the asm spin routine in
> raspi.c, which is maybe awoken too soon by some event in the mbox?

This is probably because your binary is not expecting to be
run the way that QEMU is running it. QEMU supports two
ways of starting guest code on Arm:
 (1) Linux kernels; these boot with whatever the expected
 boot protocol for the kernel on this board is. For raspi
 that will be "start the primary CPU, but put the secondaries in
 the pen waiting on the mbox". Effectively, QEMU emulates a
 very minimal bit of the firmware, just enough to boot Linux.
 (2) Not Linux kernels; these are booted as if they were the
 first thing to execute on the raw hardware, which is to say
 that all CPUs start executing at once, and it is the job of
 the guest code to provide whatever penning of secondary CPUs
 it wants to do. That is, your guest code has to do the work
 of the firmware here, because it effectively is the firmware.

We assume that you're a Linux kernel if you're a raw image,
or a suitable uImage. If you're an ELF image we assume you're
not a Linux kernel. (This is not exactly ideal but we're to
some extent lumbered with it for backwards-compatibility reasons.)

> Second problem is that u-boot relies on some SoC timer for the
> raspberrypi 2, "System Timer" in
> https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
> It has not been added to qemu, to our knowledge but it looks like it
> should be pretty easy to emulate.

Yeah, our emulation for this SoC's devices is still missing
pieces. Contributions of device models are welcome. (You
might want to check the list archives, etc -- I know there
are some bcm283x device models floating around which haven't
yet made it into mainline, which might be a workable base
for cleanup and contribution.)

thanks
-- PMM