Patchwork [RFC,5/7] vl.c: added -kerndtb option

login
register
mail settings
Submitter Peter A. G. Crosthwaite
Date Jan. 23, 2012, 7:20 a.m.
Message ID <75020d27a76d9b884a9c40d8c6ec81b525ab96a9.1327302677.git.peter.crosthwaite@petalogix.com>
Download mbox | patch
Permalink /patch/137287/
State New
Headers show

Comments

Peter A. G. Crosthwaite - Jan. 23, 2012, 7:20 a.m.
Added linux specific kernel dtb option. This option can be specified to inject
an argument device tree blob (dtb) into linux.

Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
---
 qemu-options.hx |    3 +++
 vl.c            |    4 ++++
 2 files changed, 7 insertions(+), 0 deletions(-)
Andreas Färber - Jan. 24, 2012, 7:22 a.m.
Am 23.01.2012 08:20, schrieb Peter A. G. Crosthwaite:
> Added linux specific kernel dtb option. This option can be specified to inject
> an argument device tree blob (dtb) into linux.
> 
> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> ---
>  qemu-options.hx |    3 +++
>  vl.c            |    4 ++++
>  2 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 6295cde..43cddff 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1931,6 +1931,9 @@ ETEXI
>  
>  DEF("kernel", HAS_ARG, QEMU_OPTION_kernel, \
>      "-kernel bzImage use 'bzImage' as kernel image\n", QEMU_ARCH_ALL)
> +DEF("kern-dtb", HAS_ARG, QEMU_OPTION_kerndtb, \
> +    "-kern-dtb dtb device tree blob passed to kernel boot\n", QEMU_ARCH_ALL)

We should probably call it -kernel-dtb. If there's some strncmp() from
-kernel interfering, we should fix that instead.

I don't see this variable being used anywhere in this series though.
Would it have been in the missing zynq machine of 7/7?

Andreas

> +
>  STEXI
>  @item -kernel @var{bzImage}
>  @findex -kernel
> diff --git a/vl.c b/vl.c
> index d5868b1..75246f8 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -233,6 +233,7 @@ int boot_menu;
>  uint8_t *boot_splash_filedata;
>  int boot_splash_filedata_size;
>  uint8_t qemu_extra_params_fw[2];
> +const char *qemu_kerndtb = NULL;
>  
>  typedef struct FWBootEntry FWBootEntry;
>  
> @@ -2437,6 +2438,9 @@ int main(int argc, char **argv, char **envp)
>              case QEMU_OPTION_kernel:
>                  kernel_filename = optarg;
>                  break;
> +            case QEMU_OPTION_kerndtb:
> +                qemu_kerndtb = optarg;
> +                break;
>              case QEMU_OPTION_append:
>                  kernel_cmdline = optarg;
>                  break;
Peter A. G. Crosthwaite - Jan. 24, 2012, 7:35 a.m.
Hi Andreas,

Thanks for that, I will rename the switch to -kernel-dtb.

You are correct that 7/7 should have the usage in it, that patch was
incorrectly generated, I will regenerate and resend the series tomorrow for
another review cycle.

Regards.
Peter


On Tue, Jan 24, 2012 at 5:22 PM, Andreas Färber <afaerber@suse.de> wrote:

> Am 23.01.2012 08:20, schrieb Peter A. G. Crosthwaite:
> > Added linux specific kernel dtb option. This option can be specified to
> inject
> > an argument device tree blob (dtb) into linux.
> >
> > Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> > ---
> >  qemu-options.hx |    3 +++
> >  vl.c            |    4 ++++
> >  2 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index 6295cde..43cddff 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -1931,6 +1931,9 @@ ETEXI
> >
> >  DEF("kernel", HAS_ARG, QEMU_OPTION_kernel, \
> >      "-kernel bzImage use 'bzImage' as kernel image\n", QEMU_ARCH_ALL)
> > +DEF("kern-dtb", HAS_ARG, QEMU_OPTION_kerndtb, \
> > +    "-kern-dtb dtb device tree blob passed to kernel boot\n",
> QEMU_ARCH_ALL)
>
> We should probably call it -kernel-dtb. If there's some strncmp() from
> -kernel interfering, we should fix that instead.
>
> I don't see this variable being used anywhere in this series though.
> Would it have been in the missing zynq machine of 7/7?
>
> Andreas
>
> > +
> >  STEXI
> >  @item -kernel @var{bzImage}
> >  @findex -kernel
> > diff --git a/vl.c b/vl.c
> > index d5868b1..75246f8 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -233,6 +233,7 @@ int boot_menu;
> >  uint8_t *boot_splash_filedata;
> >  int boot_splash_filedata_size;
> >  uint8_t qemu_extra_params_fw[2];
> > +const char *qemu_kerndtb = NULL;
> >
> >  typedef struct FWBootEntry FWBootEntry;
> >
> > @@ -2437,6 +2438,9 @@ int main(int argc, char **argv, char **envp)
> >              case QEMU_OPTION_kernel:
> >                  kernel_filename = optarg;
> >                  break;
> > +            case QEMU_OPTION_kerndtb:
> > +                qemu_kerndtb = optarg;
> > +                break;
> >              case QEMU_OPTION_append:
> >                  kernel_cmdline = optarg;
> >                  break;
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>
Andreas Färber - Jan. 24, 2012, 7:50 a.m.
Hi Peter,

Am 24.01.2012 08:35, schrieb Peter Crosthwaite:
> Thanks for that, I will rename the switch to -kernel-dtb.
> 
> You are correct that 7/7 should have the usage in it, that patch was
> incorrectly generated, I will regenerate and resend the series tomorrow
> for another review cycle.

Just found it, sorry. Is it just my mail client or did something go
wrong with sending? 0/7 is not threaded with the rest, and neither is
the fixed-up 7/7. It would facilitate review.

When resending, please also cc our ARM maintainer, even if your Edgar
might be the one to commit it in the end.
Please also don't forget to update MAINTAINERS with an entry for the new
machine and devices.

Regards,
Andreas
Stefan Weil - Jan. 24, 2012, 6:23 p.m.
Am 24.01.2012 08:22, schrieb Andreas Färber:
> Am 23.01.2012 08:20, schrieb Peter A. G. Crosthwaite:
>> Added linux specific kernel dtb option. This option can be specified 
>> to inject
>> an argument device tree blob (dtb) into linux.
>>
>> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
>> ---
>> qemu-options.hx | 3 +++
>> vl.c | 4 ++++
>> 2 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 6295cde..43cddff 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -1931,6 +1931,9 @@ ETEXI
>>
>> DEF("kernel", HAS_ARG, QEMU_OPTION_kernel, \
>> "-kernel bzImage use 'bzImage' as kernel image\n", QEMU_ARCH_ALL)
>> +DEF("kern-dtb", HAS_ARG, QEMU_OPTION_kerndtb, \
>> + "-kern-dtb dtb device tree blob passed to kernel boot\n", 
>> QEMU_ARCH_ALL)
>
> We should probably call it -kernel-dtb. If there's some strncmp() from
> -kernel interfering, we should fix that instead.
>
> I don't see this variable being used anywhere in this series though.
> Would it have been in the missing zynq machine of 7/7?
>
> Andreas

I'd prefer a different solution. As far as I have understood,
the dtb is only useful with a kernel, so it could be handled
as an optional attribute to the -kernel parameter:

     -kernel IMAGE[,dtb=DTB]

Of course the same applies to -append, but that's a different issue.

Regards,
Stefan
Scott Wood - Jan. 26, 2012, 7:34 p.m.
On 01/24/2012 12:23 PM, Stefan Weil wrote:
> I'd prefer a different solution. As far as I have understood,
> the dtb is only useful with a kernel, so it could be handled
> as an optional attribute to the -kernel parameter:
> 
>     -kernel IMAGE[,dtb=DTB]
> 
> Of course the same applies to -append, but that's a different issue.

-initrd as well.

This would mean you couldn't have a comma in a filename (shouldn't come
up often, but still ugly).

-Scott
Peter Maydell - Jan. 26, 2012, 7:40 p.m.
On 23 January 2012 07:20, Peter A. G. Crosthwaite
<peter.crosthwaite@petalogix.com> wrote:
> --- a/vl.c
> +++ b/vl.c
> @@ -233,6 +233,7 @@ int boot_menu;
>  uint8_t *boot_splash_filedata;
>  int boot_splash_filedata_size;
>  uint8_t qemu_extra_params_fw[2];
> +const char *qemu_kerndtb = NULL;
>
>  typedef struct FWBootEntry FWBootEntry;
>
> @@ -2437,6 +2438,9 @@ int main(int argc, char **argv, char **envp)
>             case QEMU_OPTION_kernel:
>                 kernel_filename = optarg;
>                 break;
> +            case QEMU_OPTION_kerndtb:
> +                qemu_kerndtb = optarg;
> +                break;
>             case QEMU_OPTION_append:
>                 kernel_cmdline = optarg;
>                 break;

This is inconsistent with how we handle kernel_filename
and initrd_filename (throwing things around via random
globals is a pretty nasty interface).

I think I like the approach Grant Likely suggested of
cleaning up the machine->init function signature so we
just pass it a struct instead.

Also missing the mollyguard on attempting to use -kernel-dtb
but not -kernel (cf the check done for -append and -initrd).

-- PMM
Eric Blake - Jan. 26, 2012, 9:27 p.m.
On 01/26/2012 12:34 PM, Scott Wood wrote:
> On 01/24/2012 12:23 PM, Stefan Weil wrote:
>> I'd prefer a different solution. As far as I have understood,
>> the dtb is only useful with a kernel, so it could be handled
>> as an optional attribute to the -kernel parameter:
>>
>>     -kernel IMAGE[,dtb=DTB]
>>
>> Of course the same applies to -append, but that's a different issue.
> 
> -initrd as well.
> 
> This would mean you couldn't have a comma in a filename (shouldn't come
> up often, but still ugly).

In other instances where you use a comma to separate arguments and also
want to accept commas in arbitrary file names, qemu has used the notion
of a double comma as being the escape sequence for a single comma in the
intended file name, rather than a separator for later arguments.
Markus Armbruster - Jan. 27, 2012, 8:25 a.m.
Eric Blake <eblake@redhat.com> writes:

> On 01/26/2012 12:34 PM, Scott Wood wrote:
>> On 01/24/2012 12:23 PM, Stefan Weil wrote:
>>> I'd prefer a different solution. As far as I have understood,
>>> the dtb is only useful with a kernel, so it could be handled
>>> as an optional attribute to the -kernel parameter:
>>>
>>>     -kernel IMAGE[,dtb=DTB]
>>>
>>> Of course the same applies to -append, but that's a different issue.
>> 
>> -initrd as well.
>> 
>> This would mean you couldn't have a comma in a filename (shouldn't come
>> up often, but still ugly).
>
> In other instances where you use a comma to separate arguments and also
> want to accept commas in arbitrary file names, qemu has used the notion
> of a double comma as being the escape sequence for a single comma in the
> intended file name, rather than a separator for later arguments.

Use QemuOpts for NAME=VALUE,... arguments.  Common code, common
syntactic conventions.
Peter A. G. Crosthwaite - Jan. 29, 2012, 6:51 a.m.
Hi All,

So on the topic of these command line arguments for initrd, dtb and
friends, another related issue we have encountered (and have hacked around
in our tree) is not being able to relocate the initrd or kernel. Currently
these memory locations are hardcoded in arm_boot.c:

#define KERNEL_ARGS_ADDR 0x100
#define KERNEL_LOAD_ADDR 0x00010000
#define INITRD_LOAD_ADDR 0x00d00000

If you see patch 6/7 in this same series I put in place a hack to override
the initrd location in memory, but I wonder if instead this should go up to
the command line interface as a parameter. Currently the machine model (or
arm_boot.c) defines exactly where kernels/initrds/command-line-args line in
memory, but since these are software properties should perhaps they go up
to the command line as -kernel,foo=bar options? E.G:

qemu-system-arm
-kernel,kernel-image=/foo/zImage,kernel-addr=0x00010000,initrd=/foo/initrd,initrd_addr=0x00d00000

It strikes me as broken that a machine model specifies where in memory a
kernel has to live. Something similar would apply to the dtb argument, this
patch introduces.

For the next revision of this patch series I am going to put in the
mollyguard and just use -kernel-dtb foo for the moment.

So with the greater issue of linux specific command line arguments, what is
the consensus here on how this is going to be handled with regards to:

-Passing all this command line stuff in a struct
-nesting initrd and friends under the -kernel option.

And do either of these act as a blocker on this patch series?

Regards,
Peter

On Fri, Jan 27, 2012 at 6:25 PM, Markus Armbruster <armbru@redhat.com>wrote:

> Eric Blake <eblake@redhat.com> writes:
>
> > On 01/26/2012 12:34 PM, Scott Wood wrote:
> >> On 01/24/2012 12:23 PM, Stefan Weil wrote:
> >>> I'd prefer a different solution. As far as I have understood,
> >>> the dtb is only useful with a kernel, so it could be handled
> >>> as an optional attribute to the -kernel parameter:
> >>>
> >>>     -kernel IMAGE[,dtb=DTB]
> >>>
> >>> Of course the same applies to -append, but that's a different issue.
> >>
> >> -initrd as well.
> >>
> >> This would mean you couldn't have a comma in a filename (shouldn't come
> >> up often, but still ugly).
> >
> > In other instances where you use a comma to separate arguments and also
> > want to accept commas in arbitrary file names, qemu has used the notion
> > of a double comma as being the escape sequence for a single comma in the
> > intended file name, rather than a separator for later arguments.
>
> Use QemuOpts for NAME=VALUE,... arguments.  Common code, common
> syntactic conventions.
>
John Williams - Jan. 30, 2012, 12:28 a.m.
On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
<peter.crosthwaite@petalogix.com> wrote:
> Hi All,
>
> So on the topic of these command line arguments for initrd, dtb and friends,
> another related issue we have encountered (and have hacked around in our
> tree) is not being able to relocate the initrd or kernel. Currently these
> memory locations are hardcoded in arm_boot.c:
>
> #define KERNEL_ARGS_ADDR 0x100
> #define KERNEL_LOAD_ADDR 0x00010000
> #define INITRD_LOAD_ADDR 0x00d00000
>
> If you see patch 6/7 in this same series I put in place a hack to override
> the initrd location in memory, but I wonder if instead this should go up to
> the command line interface as a parameter. Currently the machine model (or
> arm_boot.c) defines exactly where kernels/initrds/command-line-args line in
> memory, but since these are software properties should perhaps they go up to
> the command line as -kernel,foo=bar options? E.G:
>
> qemu-system-arm
> -kernel,kernel-image=/foo/zImage,kernel-addr=0x00010000,initrd=/foo/initrd,initrd_addr=0x00d00000

There's an opportunity here - QEMU needs the cmdline ability to load
random binaries/elfs anyway, such as

--load file@address

e.g. --load image.bin@0xa4000000

-- load file.elf

(no address required)

This option or one like it would make it much easier and less
hard-coded to assemble any sort of initial memory state.

Extending this, kernels, initrds and DTBs all can have
machine-specific preferred addresses but can be overriden in the same
way:

--kernel zImage@0x20000000 --initrd fs.img@0x40000000

and so on

The '@' symbol will need to be escaped by it's a pretty natural syntax.

John
John Williams - Jan. 30, 2012, 12:33 a.m.
On Mon, Jan 30, 2012 at 10:28 AM, John Williams
<john.williams@petalogix.com> wrote:
> On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
> <peter.crosthwaite@petalogix.com> wrote:
>> Hi All,
>>
>> So on the topic of these command line arguments for initrd, dtb and friends,
>> another related issue we have encountered (and have hacked around in our
>> tree) is not being able to relocate the initrd or kernel. Currently these
>> memory locations are hardcoded in arm_boot.c:
>>
>> #define KERNEL_ARGS_ADDR 0x100
>> #define KERNEL_LOAD_ADDR 0x00010000
>> #define INITRD_LOAD_ADDR 0x00d00000
>>
>> If you see patch 6/7 in this same series I put in place a hack to override
>> the initrd location in memory, but I wonder if instead this should go up to
>> the command line interface as a parameter. Currently the machine model (or
>> arm_boot.c) defines exactly where kernels/initrds/command-line-args line in
>> memory, but since these are software properties should perhaps they go up to
>> the command line as -kernel,foo=bar options? E.G:
>>
>> qemu-system-arm
>> -kernel,kernel-image=/foo/zImage,kernel-addr=0x00010000,initrd=/foo/initrd,initrd_addr=0x00d00000
>
> There's an opportunity here - QEMU needs the cmdline ability to load
> random binaries/elfs anyway, such as
>
> --load file@address
>
> e.g. --load image.bin@0xa4000000

And while we're at it how about overriding arbitrary boot PC addresses as well?

--boot-addr 0xdeadbeef

It should be possible to boot random bootrom code in QEMU without
hacking on the machine model.

qemu-system-arm -M foo --file bootrom.bin@0x000000 --boot-addr 0x00001000

We bumped into this recently - we need a cleaner way of telling QEMU
if it's pretending to be just the machine with some minimal initial
state as above(for running bootloaders, baremetal etc), or it's being
the machine *plus* a bootloader (booting vmlinux/zimage).

Currently it's pretty hacky.

John






>
> -- load file.elf
>
> (no address required)
>
> This option or one like it would make it much easier and less
> hard-coded to assemble any sort of initial memory state.
>
> Extending this, kernels, initrds and DTBs all can have
> machine-specific preferred addresses but can be overriden in the same
> way:
>
> --kernel zImage@0x20000000 --initrd fs.img@0x40000000
>
> and so on
>
> The '@' symbol will need to be escaped by it's a pretty natural syntax.
>
> John
> --
> John Williams, PhD, B. Eng, B. IT
> PetaLogix - Linux Solutions for a Reconfigurable World
> w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663
Anthony Liguori - Jan. 30, 2012, 2:10 a.m.
On 01/24/2012 12:23 PM, Stefan Weil wrote:
> Am 24.01.2012 08:22, schrieb Andreas Färber:
>> Am 23.01.2012 08:20, schrieb Peter A. G. Crosthwaite:
>>> Added linux specific kernel dtb option. This option can be specified to inject
>>> an argument device tree blob (dtb) into linux.
>>>
>>> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
>>> ---
>>> qemu-options.hx | 3 +++
>>> vl.c | 4 ++++
>>> 2 files changed, 7 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/qemu-options.hx b/qemu-options.hx
>>> index 6295cde..43cddff 100644
>>> --- a/qemu-options.hx
>>> +++ b/qemu-options.hx
>>> @@ -1931,6 +1931,9 @@ ETEXI
>>>
>>> DEF("kernel", HAS_ARG, QEMU_OPTION_kernel, \
>>> "-kernel bzImage use 'bzImage' as kernel image\n", QEMU_ARCH_ALL)
>>> +DEF("kern-dtb", HAS_ARG, QEMU_OPTION_kerndtb, \
>>> + "-kern-dtb dtb device tree blob passed to kernel boot\n", QEMU_ARCH_ALL)
>>
>> We should probably call it -kernel-dtb. If there's some strncmp() from
>> -kernel interfering, we should fix that instead.
>>
>> I don't see this variable being used anywhere in this series though.
>> Would it have been in the missing zynq machine of 7/7?
>>
>> Andreas
>
> I'd prefer a different solution. As far as I have understood,
> the dtb is only useful with a kernel, so it could be handled
> as an optional attribute to the -kernel parameter:
>
> -kernel IMAGE[,dtb=DTB]

If it looks like a device, acts like a device, and smells like a device...

The best thing to do here is to make an arm-kernel-loader device that hangs off 
of sysbus and takes four string properties.

I was going to do this shortly for PC anyway.

BTW, for unknown command line options, we should probably assume they are 
-device and treat accordingly.  So -arm-kernel-loader 
dtb=DTB,kernel=/path/to/vmlinux would Just Work.

Regards,

Anthony Liguori

>
> Of course the same applies to -append, but that's a different issue.
>
> Regards,
> Stefan
>
>
Anthony Liguori - Jan. 30, 2012, 2:11 a.m.
On 01/29/2012 06:28 PM, John Williams wrote:
> On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
> <peter.crosthwaite@petalogix.com>  wrote:
>> Hi All,
>>
>> So on the topic of these command line arguments for initrd, dtb and friends,
>> another related issue we have encountered (and have hacked around in our
>> tree) is not being able to relocate the initrd or kernel. Currently these
>> memory locations are hardcoded in arm_boot.c:
>>
>> #define KERNEL_ARGS_ADDR 0x100
>> #define KERNEL_LOAD_ADDR 0x00010000
>> #define INITRD_LOAD_ADDR 0x00d00000
>>
>> If you see patch 6/7 in this same series I put in place a hack to override
>> the initrd location in memory, but I wonder if instead this should go up to
>> the command line interface as a parameter. Currently the machine model (or
>> arm_boot.c) defines exactly where kernels/initrds/command-line-args line in
>> memory, but since these are software properties should perhaps they go up to
>> the command line as -kernel,foo=bar options? E.G:
>>
>> qemu-system-arm
>> -kernel,kernel-image=/foo/zImage,kernel-addr=0x00010000,initrd=/foo/initrd,initrd_addr=0x00d00000
>
> There's an opportunity here - QEMU needs the cmdline ability to load
> random binaries/elfs anyway, such as
>
> --load file@address

Make an elf loader device if you desire this ability but I'm skeptical that it 
really is all that useful.

No special syntax though, we have a way to parameterize options as Markus 
rightly points out.

Regards,

Anthony Liguori

>
> e.g. --load image.bin@0xa4000000
>
> -- load file.elf
>
> (no address required)
>
> This option or one like it would make it much easier and less
> hard-coded to assemble any sort of initial memory state.
>
> Extending this, kernels, initrds and DTBs all can have
> machine-specific preferred addresses but can be overriden in the same
> way:
>
> --kernel zImage@0x20000000 --initrd fs.img@0x40000000
>
> and so on
>
> The '@' symbol will need to be escaped by it's a pretty natural syntax.
>
> John
John Williams - Jan. 30, 2012, 2:19 a.m.
On Mon, Jan 30, 2012 at 12:11 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 01/29/2012 06:28 PM, John Williams wrote:
>>
>> On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
>> <peter.crosthwaite@petalogix.com>  wrote:
>>>
>>> Hi All,
>>>
>>> So on the topic of these command line arguments for initrd, dtb and
>>> friends,
>>> another related issue we have encountered (and have hacked around in our
>>> tree) is not being able to relocate the initrd or kernel. Currently these
>>> memory locations are hardcoded in arm_boot.c:
>>>
>>> #define KERNEL_ARGS_ADDR 0x100
>>> #define KERNEL_LOAD_ADDR 0x00010000
>>> #define INITRD_LOAD_ADDR 0x00d00000
>>>
>>> If you see patch 6/7 in this same series I put in place a hack to
>>> override
>>> the initrd location in memory, but I wonder if instead this should go up
>>> to
>>> the command line interface as a parameter. Currently the machine model
>>> (or
>>> arm_boot.c) defines exactly where kernels/initrds/command-line-args line
>>> in
>>> memory, but since these are software properties should perhaps they go up
>>> to
>>> the command line as -kernel,foo=bar options? E.G:
>>>
>>> qemu-system-arm
>>>
>>> -kernel,kernel-image=/foo/zImage,kernel-addr=0x00010000,initrd=/foo/initrd,initrd_addr=0x00d00000
>>
>>
>> There's an opportunity here - QEMU needs the cmdline ability to load
>> random binaries/elfs anyway, such as
>>
>> --load file@address
>
>
> Make an elf loader device if you desire this ability but I'm skeptical that
> it really is all that useful.

It is useful for non-Linux use-cases, of which there are many!

Can you explain how you'd see such a 'loader device' in practice?  How
does it get bound into the machine model?  How do we pass arguments to
it?

Thanks,

John
Anthony Liguori - Jan. 30, 2012, 2:28 a.m.
On 01/29/2012 08:19 PM, John Williams wrote:
> On Mon, Jan 30, 2012 at 12:11 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> On 01/29/2012 06:28 PM, John Williams wrote:
>>>
>>> On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
>>> <peter.crosthwaite@petalogix.com>    wrote:
>>>>
>>>> Hi All,
>>>>
>>>> So on the topic of these command line arguments for initrd, dtb and
>>>> friends,
>>>> another related issue we have encountered (and have hacked around in our
>>>> tree) is not being able to relocate the initrd or kernel. Currently these
>>>> memory locations are hardcoded in arm_boot.c:
>>>>
>>>> #define KERNEL_ARGS_ADDR 0x100
>>>> #define KERNEL_LOAD_ADDR 0x00010000
>>>> #define INITRD_LOAD_ADDR 0x00d00000
>>>>
>>>> If you see patch 6/7 in this same series I put in place a hack to
>>>> override
>>>> the initrd location in memory, but I wonder if instead this should go up
>>>> to
>>>> the command line interface as a parameter. Currently the machine model
>>>> (or
>>>> arm_boot.c) defines exactly where kernels/initrds/command-line-args line
>>>> in
>>>> memory, but since these are software properties should perhaps they go up
>>>> to
>>>> the command line as -kernel,foo=bar options? E.G:
>>>>
>>>> qemu-system-arm
>>>>
>>>> -kernel,kernel-image=/foo/zImage,kernel-addr=0x00010000,initrd=/foo/initrd,initrd_addr=0x00d00000
>>>
>>>
>>> There's an opportunity here - QEMU needs the cmdline ability to load
>>> random binaries/elfs anyway, such as
>>>
>>> --load file@address
>>
>>
>> Make an elf loader device if you desire this ability but I'm skeptical that
>> it really is all that useful.
>
> It is useful for non-Linux use-cases, of which there are many!

It's not just a matter of loading an elf binary in memory.  You probably need to 
have a specific register state set in order to run non-Linux elf binaries which 
means you'll need binary specific logic.

If all of these binaries you want to run have a well known register state, they 
you can just use fw_cfg and a piece of firmware to read the binary (which is 
basically how -kernel works on target-i386).

>
> Can you explain how you'd see such a 'loader device' in practice?  How
> does it get bound into the machine model?  How do we pass arguments to
> it?

You create a device via qdev (now QOM) that takes whatever properties you need. 
  You then do:

-device elf-loader,base=0xa00000,file=my-elf-binary

No different than adding a network card.

As I mentioned in the previous note, we probably should short cut unknown 
options as just assume they're meant for -device such that you could also do:

-elf-loader base=0xa00000,file=my-elf-binary

Regards,

Anthony Liguori

>
> Thanks,
>
> John
John Williams - Jan. 30, 2012, 2:41 a.m.
>>>> There's an opportunity here - QEMU needs the cmdline ability to load
>>>> random binaries/elfs anyway, such as
>>>>
>>>> --load file@address
>>>
>>>
>>>
>>> Make an elf loader device if you desire this ability but I'm skeptical
>>> that
>>> it really is all that useful.
>>
>>
>> It is useful for non-Linux use-cases, of which there are many!
>
>
> It's not just a matter of loading an elf binary in memory.  You probably
> need to have a specific register state set in order to run non-Linux elf
> binaries which means you'll need binary specific logic.

The machine state at bootup is very well defined - it's whatever the TRM says!

An example may help.  We are working on the Xilinx Zynq model, dual
core Cortex A-9.  We currently are able to use QEMU for the entire
flow from

cold reset ->
bootrom ->
u-boot ->
Linux

In this flow, we don't want any magic initial state, we want QEMU to
model the CPU just like the real hardware.

Equivalently, we might like to kick directly into the kernel, SMP==2 and so on.

It makes no sense to me that we should somehow use a different machine
model just to model a different boot flow on the same hardware.

Another example, we are working on remoteproc/rpmsg support so that we
can run Linux on one core, and firmware on another.  We have this
working in QEMU today, except we had to hack around the ARM boot
code's assumptions that we always want the 2nd CPU to run an WFE/WIQ
loop.  This is only true if you are running Linux *and* you want QEMU
to fake the actions of a bootloader.

If you are modelling a cold start you want those two CPUs to race
until one of them reads the CPUID register puts itself to sleep, ie
just run the bootrom.

All of these use cases are not about virtualisation, but about system
modeling and emulation, which really is where QEMU is valuable in the
embedded space.

> If all of these binaries you want to run have a well known register state,
> they you can just use fw_cfg and a piece of firmware to read the binary
> (which is basically how -kernel works on target-i386).
>
>
>>
>> Can you explain how you'd see such a 'loader device' in practice?  How
>> does it get bound into the machine model?  How do we pass arguments to
>> it?
>
>
> You create a device via qdev (now QOM) that takes whatever properties you
> need.  You then do:
>
> -device elf-loader,base=0xa00000,file=my-elf-binary
>
> No different than adding a network card.

A network card is a tangible object, it can be present in the system.
The ELF loader is just emulator cruft, a necessary evil to get the
initial state of the machine.  Should it really be on a level footing
with actual devices?

Rgds,

John
Anthony Liguori - Jan. 30, 2012, 2:48 a.m.
On Jan 29, 2012 8:41 PM, "John Williams" <john.williams@petalogix.com>
wrote:
>
> >>>> There's an opportunity here - QEMU needs the cmdline ability to load
> >>>> random binaries/elfs anyway, such as
> >>>>
> >>>> --load file@address
> >>>
> >>>
> >>>
> >>> Make an elf loader device if you desire this ability but I'm skeptical
> >>> that
> >>> it really is all that useful.
> >>
> >>
> >> It is useful for non-Linux use-cases, of which there are many!
> >
> >
> > It's not just a matter of loading an elf binary in memory.  You probably
> > need to have a specific register state set in order to run non-Linux elf
> > binaries which means you'll need binary specific logic.
>
> The machine state at bootup is very well defined - it's whatever the TRM
says!
>
> An example may help.  We are working on the Xilinx Zynq model, dual
> core Cortex A-9.  We currently are able to use QEMU for the entire
> flow from
>
> cold reset ->
> bootrom ->
> u-boot ->
> Linux
>
> In this flow, we don't want any magic initial state, we want QEMU to
> model the CPU just like the real hardware.
>
> Equivalently, we might like to kick directly into the kernel, SMP==2 and
so on.
>
> It makes no sense to me that we should somehow use a different machine
> model just to model a different boot flow on the same hardware.
>
> Another example, we are working on remoteproc/rpmsg support so that we
> can run Linux on one core, and firmware on another.  We have this
> working in QEMU today, except we had to hack around the ARM boot
> code's assumptions that we always want the 2nd CPU to run an WFE/WIQ
> loop.  This is only true if you are running Linux *and* you want QEMU
> to fake the actions of a bootloader.
>
> If you are modelling a cold start you want those two CPUs to race
> until one of them reads the CPUID register puts itself to sleep, ie
> just run the bootrom.
>
> All of these use cases are not about virtualisation, but about system
> modeling and emulation, which really is where QEMU is valuable in the
> embedded space.

I don't see how any of this is relevant.  Presumably, on real hardware, you
have a rom bank wired to a specific physical address with ip fixed to an
address which happens to be in that space?

Why not just use an emulated flash chip?

>
> > If all of these binaries you want to run have a well known register
state,
> > they you can just use fw_cfg and a piece of firmware to read the binary
> > (which is basically how -kernel works on target-i386).
> >
> >
> >>
> >> Can you explain how you'd see such a 'loader device' in practice?  How
> >> does it get bound into the machine model?  How do we pass arguments to
> >> it?
> >
> >
> > You create a device via qdev (now QOM) that takes whatever properties
you
> > need.  You then do:
> >
> > -device elf-loader,base=0xa00000,file=my-elf-binary
> >
> > No different than adding a network card.
>
> A network card is a tangible object, it can be present in the system.
> The ELF loader is just emulator cruft, a necessary evil to get the
> initial state of the machine.  Should it really be on a level footing
> with actual devices?

All systems have to bootstrap software some how.  Some device is reasonable
for this.  This isn't emulated magic :-)

Regards,

Anthony Liguori

>
> Rgds,
>
> John
> --
> John Williams, PhD, B. Eng, B. IT
> PetaLogix - Linux Solutions for a Reconfigurable World
> w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663
John Williams - Feb. 1, 2012, 2:06 a.m.
On Mon, Jan 30, 2012 at 12:48 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>
> On Jan 29, 2012 8:41 PM, "John Williams" <john.williams@petalogix.com>
> wrote:
>>
>> >>>> There's an opportunity here - QEMU needs the cmdline ability to load
>> >>>> random binaries/elfs anyway, such as
>> >>>>
>> >>>> --load file@address
>> >>>
>> >>>
>> >>>
>> >>> Make an elf loader device if you desire this ability but I'm skeptical
>> >>> that
>> >>> it really is all that useful.
>> >>
>> >>
>> >> It is useful for non-Linux use-cases, of which there are many!
>> >
>> >
>> > It's not just a matter of loading an elf binary in memory.  You probably
>> > need to have a specific register state set in order to run non-Linux elf
>> > binaries which means you'll need binary specific logic.
>>
>> The machine state at bootup is very well defined - it's whatever the TRM
>> says!
>>
>> An example may help.  We are working on the Xilinx Zynq model, dual
>> core Cortex A-9.  We currently are able to use QEMU for the entire
>> flow from
>>
>> cold reset ->
>> bootrom ->
>> u-boot ->
>> Linux
>>
>> In this flow, we don't want any magic initial state, we want QEMU to
>> model the CPU just like the real hardware.
>>
>> Equivalently, we might like to kick directly into the kernel, SMP==2 and
>> so on.
>>
>> It makes no sense to me that we should somehow use a different machine
>> model just to model a different boot flow on the same hardware.
>>
>> Another example, we are working on remoteproc/rpmsg support so that we
>> can run Linux on one core, and firmware on another.  We have this
>> working in QEMU today, except we had to hack around the ARM boot
>> code's assumptions that we always want the 2nd CPU to run an WFE/WIQ
>> loop.  This is only true if you are running Linux *and* you want QEMU
>> to fake the actions of a bootloader.
>>
>> If you are modelling a cold start you want those two CPUs to race
>> until one of them reads the CPUID register puts itself to sleep, ie
>> just run the bootrom.
>>
>> All of these use cases are not about virtualisation, but about system
>> modeling and emulation, which really is where QEMU is valuable in the
>> embedded space.
>
> I don't see how any of this is relevant.  Presumably, on real hardware, you
> have a rom bank wired to a specific physical address with ip fixed to an
> address which happens to be in that space?

Certainly a ROM makes sense to model as a device - there is a physical
equivalent.  I'm just not so sure about a virtual device whos job is
to bus master stuffing contents into some other memory.  For example,
with such an 'ELF loader' device - when ecaxtly should it do the load?
 Do you end up with a race at system init time?

> Why not just use an emulated flash chip?

If there is a bus addressable memory with fixed contents then that can
be modelled with a device.  I'm talking about an intermediate mode
where we would like to be able to prepopulate memory with arbitrary
contents.  Half way between 'model a ROM device with the bootrom', and
the hacky 'QEMU is also sometimes a Linux bootloader' approach taken
for booting VMLinux images.

>> > If all of these binaries you want to run have a well known register
>> > state,
>> > they you can just use fw_cfg and a piece of firmware to read the binary
>> > (which is basically how -kernel works on target-i386).
>> >
>> >
>> >>
>> >> Can you explain how you'd see such a 'loader device' in practice?  How
>> >> does it get bound into the machine model?  How do we pass arguments to
>> >> it?
>> >
>> >
>> > You create a device via qdev (now QOM) that takes whatever properties
>> > you
>> > need.  You then do:
>> >
>> > -device elf-loader,base=0xa00000,file=my-elf-binary
>> >
>> > No different than adding a network card.
>>
>> A network card is a tangible object, it can be present in the system.
>> The ELF loader is just emulator cruft, a necessary evil to get the
>> initial state of the machine.  Should it really be on a level footing
>> with actual devices?
>
> All systems have to bootstrap software some how.  Some device is reasonable
> for this.  This isn't emulated magic :-)

Sure.  I just have some questions about the behavioural semantics of
an ELF/binary loader device, vs recognising this loading function as a
role for a 'deus ex machina'

John

Patch

diff --git a/qemu-options.hx b/qemu-options.hx
index 6295cde..43cddff 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1931,6 +1931,9 @@  ETEXI
 
 DEF("kernel", HAS_ARG, QEMU_OPTION_kernel, \
     "-kernel bzImage use 'bzImage' as kernel image\n", QEMU_ARCH_ALL)
+DEF("kern-dtb", HAS_ARG, QEMU_OPTION_kerndtb, \
+    "-kern-dtb dtb device tree blob passed to kernel boot\n", QEMU_ARCH_ALL)
+
 STEXI
 @item -kernel @var{bzImage}
 @findex -kernel
diff --git a/vl.c b/vl.c
index d5868b1..75246f8 100644
--- a/vl.c
+++ b/vl.c
@@ -233,6 +233,7 @@  int boot_menu;
 uint8_t *boot_splash_filedata;
 int boot_splash_filedata_size;
 uint8_t qemu_extra_params_fw[2];
+const char *qemu_kerndtb = NULL;
 
 typedef struct FWBootEntry FWBootEntry;
 
@@ -2437,6 +2438,9 @@  int main(int argc, char **argv, char **envp)
             case QEMU_OPTION_kernel:
                 kernel_filename = optarg;
                 break;
+            case QEMU_OPTION_kerndtb:
+                qemu_kerndtb = optarg;
+                break;
             case QEMU_OPTION_append:
                 kernel_cmdline = optarg;
                 break;