Patchwork [v2,1/2] arm_boot: Assume Linux boot flow when -dtb given

login
register
mail settings
Submitter Peter A. G. Crosthwaite
Date June 18, 2012, 1:35 a.m.
Message ID <54bd7599198754771c6dc3f658f4cab74ede93b2.1339982763.git.peter.crosthwaite@petalogix.com>
Download mbox | patch
Permalink /patch/165368/
State New
Headers show

Comments

Peter A. G. Crosthwaite - June 18, 2012, 1:35 a.m.
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(-)
Peter Maydell - June 19, 2012, 1:06 p.m.
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
Peter A. G. Crosthwaite - June 20, 2012, 1:45 a.m.
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
Peter A. G. Crosthwaite - June 22, 2012, 1:27 p.m.
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
Peter Maydell - June 22, 2012, 1:36 p.m.
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
Peter A. G. Crosthwaite - June 22, 2012, 1:43 p.m.
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
Peter A. G. Crosthwaite - June 22, 2012, 1:54 p.m.
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

Patch

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,