On Tue, Dec 17, 2013 at 10:58 AM, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > On 17 December 2013 00:52, Peter Crosthwaite > <peter.crosthwaite@xxxxxxxxxx> wrote: >> On Fri, Dec 13, 2013 at 8:05 PM, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: >>> 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 }, >> >> >> 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 > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm