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

[Peter Crosthwaite]

On Tue, Dec 17, 2013 at 10:58 AM, Peter Maydell
<address@hidden> wrote:
> 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.

So Zynq is very different. It just rewrites the vector table and
resets the secondarys from peripherals rst controller.

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).
>

It seems a bit board-specific and an obstacle to ultimately sanitizing
the embedded bootloaders across the architectures (I hope to one day
boot MB and ARM with one BL once I get the arch-isms out of the boot
flow).

I have another problem while we are on the bootstrap discussion - In
Zynq we have some Linux specific bootstrap issues out in device land.
Our clock driver expects the bootloader to setup some state:

https://github.com/Xilinx/meta-xilinx/blob/master/recipes-devtools/qemu/files/HACK_zynq_slcr_Bring_SLCR_out_of_reset_in_kernel_state.patch

This seems similar to the Vexpress GIC requirement - peripherals
needing linux specific setup. Can we solve both problems here with a
bit or framework allowing devs to have an alternate Linux-specific
reset state?

Then we can ditch on the machine code too :)

Regards,
Peter

>>>>> +    { 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
>