Ping! Any thoughts Peter?
Regards, Peter On Wed, Jun 20, 2012 at 11:45 AM, Peter Crosthwaite <peter.crosthwa...@petalogix.com> wrote: > 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
