On 17 December 2013 01:24, Peter Crosthwaite
<peter.crosthwaite@xxxxxxxxxx> wrote:
> 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.
Yeah. This is why boot.c supports letting the board provide its
own secondary boot code string (used by exynos and highbank).
> 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 :)
I'm not convinced about this at all -- this would be letting the
"I know about booting Linux" code spread out from boot.c
where it currently is into every device. That sounds like a bad idea.
-- PMM
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
