| Message ID | 75020d27a76d9b884a9c40d8c6ec81b525ab96a9.1327302677.git.peter.crosthwaite@petalogix.com |
|---|---|
| State | New |
| Headers | show |
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;
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 >
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
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
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
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
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.
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.
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. >
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
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
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 > >
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
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
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
>>>> 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
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
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
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;
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(-)