It matches my flow in the real hardware. Heres the scenario where we need this (FYI applies to both microblaze and arm):
User creates a Linux elf that includes a built in dtb. Slave mode bootloader boots the real hardware with the elf (my actual real JTAG bootloader work with elfs). However QEMU doesn't support all the hardware devices the kernel supports, so we need the QEMU linux bootloader to override the built in DTB (with -dtb) to stop the kernel probing non-existent devices. So, if the user specifies a dtb, adopt the linux bootloader flow instead, before jumping to the elf entry point. r2 get set to the -dtb argument and it boots with the modified dtb. Make sense? It all comes down to I need a bootloader functionality (mainly dtb but SMP stuff would be nice too) before booting my elf. Every time i touch this arm bootloader we end up in a discussion about how it needs to be rewritten cos of flawed assumptions etc (like elfs are not Linux). Can we just accept this and throw it out with the trash when someone refactors the arm bootloader properly? Regards, Peter On Tue, Jun 19, 2012 at 11:06 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 18 June 2012 02:35, Peter A. G. Crosthwaite > <peter.crosthwa...@petalogix.com> wrote: >> If the user boots with a -dtb assume the Linux boot flow, even when handling >> an >> elf. > > We don't do this for -initrd, why should we do it for -dtb ? Maybe we should do it for initrd too. If the user specifies either of these options they are trying to boot Linux. > > -- PMM
