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

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

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

So here are some of the problems im trying to solve with the bootloader:

Smp bootstrap secondary CPUs while loading an elf (currently elfs will be
assumed to be not kernels).
Change the kernel, initrd and dtb load address on the command line.
Use my own SMP secondary bootloop.

My intention with this patch was to set myself to do boot parameterizations
on the command line by just adding them as qdev props to the
arm_linux_loader and set them using -device instantiation. E.G. -device
arm_boot_loader,initrd_addr=0x10000000. But if I take the approach you are
suggesting, the for this initrd load address option, I would need to add
myself a command line option, fetch that command line option in every arm
machine model and then pass it to arm_load_kernel. The change pattern is
huge and is intrusive to every arm machine model. Whereas what I am
suggesting would limit changes to only the bootloader device.

2012/2/9 Paul Brook <paul@codesourcery.com>

> > Its the other problem I am more worried about, i.e. when I -device
> > instantiate my bootloader with an existing machine how do I get my
> ram_size
> > and board_ID? The no machine opts for devices policy makes this
> impossible
> > such that I would have to pass in board_id and ram_size to
> > the boot-loader on the command line. Is there any acceptable way where
> the
> > machine model can make something globally available to devices for the
> > purpose of instantiating them with -device?
>
> I'm not convinved this is a problem worth solving. i.e. is it really worth
> consirering the bootloader a user-replaceable part of the machine (without
> actually changing the machine description)?  Making our bootloader not suck
> seems a better option.
>
> Paul
>

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