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.mayd...@linaro.org> wrote: > > On 17 December 2013 00:52, Peter Crosthwaite > > <peter.crosthwa...@xilinx.com> wrote: > >> On Fri, Dec 13, 2013 at 8:05 PM, Peter Maydell <peter.mayd...@linaro.org> > >> wrote: > >>> On 13 December 2013 03:19, Peter Crosthwaite > >>> <peter.crosthwa...@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 > kvm...@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm -- Christoffer