|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RFC PATCH 5/7] vl.c: added -kerndtb option |
Date: | Sun, 29 Jan 2012 20:28:30 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 |
On 01/29/2012 08:19 PM, John Williams wrote:
On Mon, Jan 30, 2012 at 12:11 PM, Anthony Liguori<address@hidden> wrote:On 01/29/2012 06:28 PM, John Williams wrote:On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite <address@hidden> 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=0x00d00000There's an opportunity here - QEMU needs the cmdline ability to load random binaries/elfs anyway, such as --load address@hiddenMake 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
[Prev in Thread] | Current Thread | [Next in Thread] |