| Message ID | 54bd7599198754771c6dc3f658f4cab74ede93b2.1339982763.git.peter.crosthwaite@petalogix.com |
|---|---|
| State | New |
| Headers | show |
On 18 June 2012 02:35, Peter A. G. Crosthwaite <peter.crosthwaite@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 ? -- PMM
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.maydell@linaro.org> wrote: > On 18 June 2012 02:35, Peter A. G. Crosthwaite > <peter.crosthwaite@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
Ping! Any thoughts Peter? Regards, Peter On Wed, Jun 20, 2012 at 11:45 AM, Peter Crosthwaite <peter.crosthwaite@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.maydell@linaro.org> wrote: >> On 18 June 2012 02:35, Peter A. G. Crosthwaite >> <peter.crosthwaite@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
On 22 June 2012 14:27, Peter Crosthwaite <peter.crosthwaite@petalogix.com> wrote: > Ping! > > Any thoughts Peter? Still sounds too specific to your odd use case and hardware to me. I'd accept some reasonable way of saying "this ELF file is a Linux kernel", but magically doing it if you also said -dtb isn't it. I also care about backcompat with previous command lines and with being consistent about how -kernel works across architectures where possible. (I know this is a somewhat contradictory set of requirements.) -- PMM
On Fri, Jun 22, 2012 at 11:36 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 22 June 2012 14:27, Peter Crosthwaite > <peter.crosthwaite@petalogix.com> wrote: >> Ping! >> >> Any thoughts Peter? > > Still sounds too specific to your odd use case and hardware to me. > > I'd accept some reasonable way of saying "this ELF file is a Linux kernel", > but magically doing it if you also said -dtb isn't it. Then is there no objection to v1 of this series where I made a is_linux machine opt? I made this patch as a less intrusive workaround to this problem... I also care about > backcompat with previous command lines and with being consistent about > how -kernel works across architectures where possible. (I know this is > a somewhat contradictory set of requirements.) > > -- PMM
On Fri, Jun 22, 2012 at 11:36 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 22 June 2012 14:27, Peter Crosthwaite > <peter.crosthwaite@petalogix.com> wrote: >> Ping! >> >> Any thoughts Peter? > > Still sounds too specific to your odd use case and hardware to me. > > I'd accept some reasonable way of saying "this ELF file is a Linux kernel", > but magically doing it if you also said -dtb isn't it. I also care about > backcompat with previous command lines and with being consistent about > how -kernel works across architectures where possible. Speaking of other archs, microblaze will accept -dtb with an elf and implement the r2=foo style behviour before loading the elf entry. A provocative thought, how bout always using a Linux style bootloader no matter what? Does it really matter if your elf is bootstrapped by half a dozen instructions? Further to that, can we get rid of the bootloader blob altogether and just setup the cpu->env like other architectures do? 23 /* The worlds second smallest bootloader. Set r0-r2, then jump to kernel. */ 24 static uint32_t bootloader[] = { 25 0xe3a00000, /* mov r0, #0 */ 26 0xe59f1004, /* ldr r1, [pc, #4] */ 27 0xe59f2004, /* ldr r2, [pc, #4] */ 28 0xe59ff004, /* ldr pc, [pc, #4] */ 29 0, /* Board ID */ 30 0, /* Address of kernel args. Set by integratorcp_init. */ 31 0 /* Kernel entry point. Set by integratorcp_init. */ 32 }; All this code does is set registers and an entry point, which several bootloaders do just though cpu->env manipulation. > a somewhat contradictory set of requirements.) > > -- PMM
diff --git a/hw/arm_boot.c b/hw/arm_boot.c index 7447f5c..f0fa23c 100644 --- a/hw/arm_boot.c +++ b/hw/arm_boot.c @@ -360,6 +360,11 @@ void arm_load_kernel(CPUARMState *env, struct arm_boot_info *info) exit(1); } info->entry = entry; + + if (info->dtb_filename) { + is_linux = 1; + } + if (is_linux) { if (info->initrd_filename) { initrd_size = load_image_targphys(info->initrd_filename,
If the user boots with a -dtb assume the Linux boot flow, even when handling an elf. Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com> --- hw/arm_boot.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)