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

[Christoffer Dall <christoffer.dall@linaro.org>]

On Tue, Dec 17, 2013 at 11:24:45AM +1000, Peter Crosthwaite wrote:
> On Tue, Dec 17, 2013 at 10:58 AM, Peter Maydell
> <peter.maydell@linaro.org> wrote:
> > On 17 December 2013 00:52, Peter Crosthwaite
> > <peter.crosthwaite@xilinx.com> wrote:
> >> On Fri, Dec 13, 2013 at 8:05 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> >>> On 13 December 2013 03:19, Peter Crosthwaite
> >>> <peter.crosthwaite@xilinx.com> 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).

ARM is already making a good effort at this with PSCI.  However,
supporting this in TCG requires some secure state / hyp mode emulation
that we don't have currently, afaik. 

> 
> 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
> >
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

-- 
Christoffer