2012/2/8 Paul Brook
<address@hidden>
> > I suspect we want to replace the arm_load_kernel call with an
> > arm_linux_loader device with appropriate properties.
>
> Ok, so does this mean the machine model would still explicitly instantiate
> the bootloader device?
Yes. Bootloaders inherently have machine specific knowledge. They need to
know ram location, board ID, secondary CPU boot protocols, etc. Requiring the
user specify all these things separately from the rest of the machine
description is IMO not acceptable.
So what im suggesting here is that machines export these properties to a globally accessible location. Perhaps via the machine opts mechanism? Then we are in a best of both worls situation where machine models do not need bootloader awareness yet bootloaders can still query qemu for ram_size, smp#, board_id and friends.
> Will there be a way of removing the bootloader from
> the machine model so if I need to create my own custom bootloader flow i
> can? We are doing some custom non-linux boots in our application where
> arm-boot.c is not working for us so being able to swap out arm_boot.c for
> another implemenation is one of our goals. The bootloader-as-a-device flow
> is ideal for this but only works if a user can choose their bootloader on
> the command line.
I think that's solved the same lines as any other custom machine variant.
It's also part of the reason I think it's important to cleanly separate
devices that provide functionality from those that are just convenience
objects for creating a particular assembly of devices.
Having generic ELF and maybe binary blob image loaders is certainly useful.
They can all coexist happily within the same machine.
I'm inclined to say that anything else isn't worth the effort. Users with
other special needs can use third party tools[1] to embed/wrap their magic in
a regular image.
Paul
[1] In many cases cases you just need to splat the supplied bootloader+kernel
images into ram, not postprocessing is necessary. For most of the rest
objcopy is sufficient.