Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition

[Paul Brook <paul@codesourcery.com>]

> > 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.

> 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.