[Qemu-devel] ARM bootloader boot blobbing.

[Qemu-devel] ARM bootloader boot blobbing.

[Peter Crosthwaite]

Hi All,

Can anyone think of a reason why the arm primary bootloader cant be
done by just direct interaction with the CPU? Currently we have this
...

/* The worlds second smallest bootloader.  Set r0-r2, then jump to kernel.  */
static uint32_t bootloader[] = {
  0xe3a00000, /* mov     r0, #0 */
  0xe59f1004, /* ldr     r1, [pc, #4] */
  0xe59f2004, /* ldr     r2, [pc, #4] */
  0xe59ff004, /* ldr     pc, [pc, #4] */
  0, /* Board ID */
  0, /* Address of kernel args.  Set by integratorcp_init.  */
  0  /* Kernel entry point.  Set by integratorcp_init.  */
};

... which gets injected into RAM then we set the PC to this blob and
go. But couldnt we just set R0-2 directly from the bootloader and just
straight to the kernel entry point? Why do we have to blob in a
lightweight bootloader?

Regards,
Peter

Re: [Qemu-devel] ARM bootloader boot blobbing.

[Edgar E. Iglesias]

On Wed, Sep 26, 2012 at 04:27:57PM +1000, Peter Crosthwaite wrote:
> Hi All,
> 
> Can anyone think of a reason why the arm primary bootloader cant be
> done by just direct interaction with the CPU? Currently we have this
> ...
> 
> /* The worlds second smallest bootloader.  Set r0-r2, then jump to kernel.  */
> static uint32_t bootloader[] = {
>   0xe3a00000, /* mov     r0, #0 */
>   0xe59f1004, /* ldr     r1, [pc, #4] */
>   0xe59f2004, /* ldr     r2, [pc, #4] */
>   0xe59ff004, /* ldr     pc, [pc, #4] */
>   0, /* Board ID */
>   0, /* Address of kernel args.  Set by integratorcp_init.  */
>   0  /* Kernel entry point.  Set by integratorcp_init.  */
> };
> 
> ... which gets injected into RAM then we set the PC to this blob and
> go. But couldnt we just set R0-2 directly from the bootloader and just
> straight to the kernel entry point? Why do we have to blob in a
> lightweight bootloader?

Hi Peter,

I can't speak for this specific case but I've used similar approaches
for other boards when needing more realistic emulation, e.g if emulating
possible boot loaders in rom and supporting warm jumps back to the rom etc.

Cheers

Re: [Qemu-devel] ARM bootloader boot blobbing.

[Peter Crosthwaite]

On Thu, Sep 27, 2012 at 7:52 AM, Edgar E. Iglesias
<edgar.iglesias@gmail.com> wrote:
> On Wed, Sep 26, 2012 at 04:27:57PM +1000, Peter Crosthwaite wrote:
>> Hi All,
>>
>> Can anyone think of a reason why the arm primary bootloader cant be
>> done by just direct interaction with the CPU? Currently we have this
>> ...
>>
>> /* The worlds second smallest bootloader.  Set r0-r2, then jump to kernel.  */
>> static uint32_t bootloader[] = {
>>   0xe3a00000, /* mov     r0, #0 */
>>   0xe59f1004, /* ldr     r1, [pc, #4] */
>>   0xe59f2004, /* ldr     r2, [pc, #4] */
>>   0xe59ff004, /* ldr     pc, [pc, #4] */
>>   0, /* Board ID */
>>   0, /* Address of kernel args.  Set by integratorcp_init.  */
>>   0  /* Kernel entry point.  Set by integratorcp_init.  */
>> };
>>
>> ... which gets injected into RAM then we set the PC to this blob and
>> go. But couldnt we just set R0-2 directly from the bootloader and just
>> straight to the kernel entry point? Why do we have to blob in a
>> lightweight bootloader?
>
> Hi Peter,
>
> I can't speak for this specific case but I've used similar approaches
> for other boards when needing more realistic emulation, e.g if emulating
> possible boot loaders in rom and supporting warm jumps back to the rom etc.
>

Cant you just do the CPU register setting warm as well however? Im
looking at microblaze_boot.c and comparing it to ARM, here it is:

static void main_cpu_reset(void *opaque)
{
    MicroBlazeCPU *cpu = opaque;
    CPUMBState *env = &cpu->env;

    cpu_reset(CPU(cpu));
    env->regs[5] = boot_info.cmdline;
    env->regs[7] = boot_info.fdt;
    env->sregs[SR_PC] = boot_info.bootstrap_pc;
    if (boot_info.machine_cpu_reset) {
        boot_info.machine_cpu_reset(cpu);
    }
}

They seem to me to be feature equivalent with respect to register and
PC setting, yet microblaze is much simpler. Only broken case I can see
is if the guest explicitly wants to jump back to the blob without an
actual reset, however that is impossible in ARM as the bootloader does
not pass its location to the guest so the guest cant jump to the right
place. If we want to support more complex bootloaders that the guest
interacts with, then isnt that guest in itself?

Regards,
Peter

> Cheers