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

[Peter Crosthwaite <peter.crosthwaite@petalogix.com>]

[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]

2012/2/8 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.
>
>
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.
>

[-- Attachment #2: Type: text/html, Size: 2761 bytes --]