On 13 December 2013 03:19, Peter Crosthwaite
<peter.crosthwaite@xxxxxxxxxx> wrote:
> Why do we need blobs at all? Cant we just fix arm/boot to directly
> setup the CPU state to the desired? Rather than complex blobs that
> execute ARM instructions just manipulate the regs directly.
We could in theory do this for the primary bootloader, but
the secondary CPU blob has to have a loop in it so we
can sit around waiting for the guest code running in the
primary to tell us it's time to go:
>> +static const ARMInsnFixup smpboot[] = {
>> + { 0xe59f2028 }, /* ldr r2, gic_cpu_if */
>> + { 0xe59f0028 }, /* ldr r0, startaddr */
>> + { 0xe3a01001 }, /* mov r1, #1 */
>> + { 0xe5821000 }, /* str r1, [r2] - set GICC_CTLR.Enable */
>> + { 0xe3a010ff }, /* mov r1, #0xff */
>> + { 0xe5821004 }, /* str r1, [r2, 4] - set GIC_PMR.Priority to 0xff */
>> + { 0, FIXUP_DSB }, /* dsb */
>> + { 0xe320f003 }, /* wfi */
>> + { 0xe5901000 }, /* ldr r1, [r0] */
>> + { 0xe1110001 }, /* tst r1, r1 */
>> + { 0x0afffffb }, /* beq <wfi> */
>> + { 0xe12fff11 }, /* bx r1 */
>> + { 0, FIXUP_GIC_CPU_IF },
>> + { 0, FIXUP_BOOTREG },
>> + { 0, FIXUP_TERMINATOR }
>> };
We're also writing to devices here, and it's cleaner to do that
by running a guest code instruction than by somehow having
the boot code ferret around inside the device's implementation
pre-start, I think.
thanks
-- PMM
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
