Re: [Qemu-devel] [PATCH 5/7] hw/arm/boot: Allow easier swapping in of different loader code

[Peter Maydell]

On 17 December 2013 00:52, Peter Crosthwaite
<address@hidden> wrote:
> On Fri, Dec 13, 2013 at 8:05 PM, Peter Maydell <address@hidden> wrote:
>> On 13 December 2013 03:19, Peter Crosthwaite
>> <address@hidden> 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 },
>
>
> Reading up on Christopher's Kernel documentation link:
>
> Documentation/arm64/booting.txt
> Documentation/arm/Booting
>
> I can't see any reference to GIC, where are these GICisms coming from?

v7 secondary CPU boot protocol is platform specific,
though most boards seem to do something vaguely
vexpress like. The kernel expects that we've set the
GIC up so that the primary CPU can do an IPI to get
the secondary out of the holding pen loop (that's the
"wfi / ldr /tst / beq" sequence, which loops waiting
for a CPU interrupt).

>>>> +    { 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.
>
> dma_memory_write(&address_space_memory, ...
>
> Its a level above ferreting, and a level below the machine code blob.

This doesn't work in the reset hook because you can't guarantee
that this reset hook gets run after the device resets itself rather
than before...

thanks
-- PMM