Released with version 2.8
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/808737
Title:
No option to load additional binary files
I think this problem should be fixed with the new generic loader device:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e481a1f6
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Just to add to my use case.
Currently, to load a test binary called arm_test.bin.patched i have
hacked QEMU in the following manner:
diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index bfac982..e4873d4 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -280,6 +280,13 @@ void arm_load_kernel(CPUState
I am trying to develop a lightweight hypervisor for ARM Cortex-A8. In my
case I have to load hypervisor elf as kernel and there and number of
other binaries like flattened device tree binary for hypervisor
configuration, guest kernel binary, guest ramdisk, etc.
Currently, I am developing it for
On Mon, Jul 11, 2011 at 3:14 PM, Anup Patel 808...@bugs.launchpad.net wrote:
I am trying to develop a lightweight hypervisor for ARM Cortex-A8. In my
case I have to load hypervisor elf as kernel and there and number of
other binaries like flattened device tree binary for hypervisor
On 11 July 2011 16:23, Stefan Hajnoczi stefa...@gmail.com wrote:
Doesn't arm_boot.c already load an arbitrary binary when the image is
neither a kernel ELF or uboot image? I don't know the arm_boot.c
details but skimming the source shows it already does
load_image_targphys().
The assumption
I understand that we should not change -kernel option for backwards
compatibility, that's why I suggest some new option for loading
arbitrary binary file (not necessarily ELF file). This option would just
mean: Just blindly load the given file to the given physical address.
We can also pass this
