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