On Fri, 23 Aug 2019 at 16:54, Bonnans, Laurent <laurent.bonn...@here.com> 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
