Well, ok playing with the cpio options seems to have done the trick:
zcat ../arm_test.img | cpio -idmv
find . | cpio -ov -R root --format=newc | gzip > ../test.img
I can boot the new image now, and run my test app - of course it didn't work, its giving
me "Floating point exception", lol.
Pretty sure I have the correct cross compile tool chain, and its a simple main
program to just return a value - no libs required - well thats not entirely
true - it has all that std c/gnu garbage.
Still, I did not expect a floating point exception...
________________________________________
From: Brooke Wallace
Sent: Thursday, November 03, 2016 4:33 PM
To: Peter Maydell
Cc: address@hidden
Subject: RE: [Qemu-discuss] sharing files between host and guest
Well, I was able to unpack the arm_test.img and add my file, but after
repacking and using as a boot image I get a Kernel panic - not syncing: VFS:
Unable to mount root fs unknown-block(0,0)
Pretty sure there must be some different options in use than whats given at the
link https://access.redhat.com/solutions/24029
________________________________________
From: Peter Maydell address@hidden
Sent: Thursday, November 03, 2016 4:03 PM
To: Brooke Wallace
Cc: address@hidden
Subject: Re: [Qemu-discuss] sharing files between host and guest
On 3 November 2016 at 22:48, Brooke Wallace <address@hidden> wrote:
Thanks again Peter,
Is there anyway to mount an -initrd image to the host?
You can't directly mount it, because it's not a filesystem.
But there are tools for manipulating initrd images:
something like https://access.redhat.com/solutions/24029
should work at a very low level, and there's probably
some higher-level tools as well. The same things that
work for manipulating an initrd for your host system
should work just as well on one for the guest.
I'm not interested in booting Windows, and don't require
a full blown Debian OS - in fact I would expect a busybox
image for an embedded device.
A full OS is much easier to work with, because you
don't have to keep recreating an embedded filesystem
image every time you do anything, and you don't need
to go through the pain of assembling and cross
compiling lots of library dependencies for every
program you want to use inside the VM.
From QEMU's point of view there's no difference,
it's just running a kernel and some userspace programs,
so you might as well pick the userspace that's easy
to work with. (If you want an embedded fs image
you could have a look at https://buildroot.org, but
it's likely to be more work to get that running than
just to use Debian.)
Then maybe an API or some docs providing a description
of how one is expected to modify the code (well
implementing plugins would be best) to emulate
their particular hardware.
We deliberately don't have a plugin architecture.
New board and device models should be implemented
in QEMU's source tree and (ideally) upstreamed.
The "how to add a new board or devices" is unfortunately
still at the level of "look at one that was added
recently and see how it was done".
thanks
-- PMM