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 [peter.mayd...@linaro.org] Sent: Thursday, November 03, 2016 4:03 PM To: Brooke Wallace Cc: qemu-discuss@nongnu.org Subject: Re: [Qemu-discuss] sharing files between host and guest On 3 November 2016 at 22:48, Brooke Wallace <bwall...@ramlabs.com> 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