Ah, I've been missing out on a whole host of ARM instructions. I haven't
tried it yet, but I should be able to get it working from here. Thanks
so much for your help!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launch
You can look at hw/arm/raspi.c::write_smpboot():
While the first core start booting the kernel, the other cores keep
spinning until the 1st core configured the mailboxes:
static const uint32_t smpboot[] = {
0xe1a0e00f, /*mov lr, pc */
0xe3a0fe00 + (BOARDSETUP_ADDR >> 4), /* mov pc
Aha! So this is not a bug after all, but an intentional feature.
Does "deal with handling all the secondary cores" basically mean
"detecting what core I'm currently running on, and continuing only if
it's the primary core"? If so, it's not clear to me how I could do this.
I tried a few obvious ide
Hi Evan,
Your suspicion is correct, the QEMU model starts with the four cores
powered on, so your code is likely running on each core in simultaneous.
The hardware booting process is described [1]: your code is loaded as
the firmware loads kernel.img (the last step).
The ARM maintainer suggested
I just noticed that on lines 53 and 55 of the attached file, I forgot to
replace the register "r0" with its alias "address". Fixing these lines
doesn't change the behavior of the program.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU
