Thanks for the sympathy Peter. Unfortunately the lack of documentation and
reasonable introductory guide is making this a non-starter for us.
1. The integratorcp test image does not have scp
the only command I can find for file transfer is tftp, but it looks like no
one uses this anymore
I also don't see another way to confirm network connectivity given that ping
is expected to not work.
2. I still don't understand why I can't map the disk image "arm_root.img" to my
host.
I assume it has something to do with the fact that its passed to qemu as an
-initrd image and not a -hda image?
fdisk does not show any partitions or offset for this image to use in the
mount command, but mount complains:
$ sudo mount -t auto -o loop arm_root.img /mnt/qemu
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
There is nothing in dmesg or journalctl
I'll can give "vrit" a try, but I'm looking for a working example that can be
mapped to real hardware, eg. RaspberryPI, Beagle Bone Black or something
similar. Working in a emulation for a virtual machine does me no good. Our goal
is to emulate actual hardware and ultimately understand how to modify QEMU to
add hooks and add emulations for new hardware.
Lack of good initial user documentation and a set of working examples will be a
setback. One must be comfortable with and understand how the software is
supposed to work before considering modification and reverse engineering is way
too time consuming.
I can see that lack of any API for adding emulations, or documentation of an
API is also going to be an issue for us here as well when considering whether
or not to invest our time in this effort.
I know that QEMU is part of the Android emulation, and I wonder if going that
route may be more productive - although were really not interested in android.
________________________________________
From: Peter Maydell [peter.mayd...@linaro.org]
Sent: Thursday, November 03, 2016 4:25 AM
To: Brooke Wallace
Cc: qemu-discuss@nongnu.org
Subject: Re: [Qemu-discuss] sharing files between host and guest
On 2 November 2016 at 20:03, Brooke Wallace <bwall...@ramlabs.com> wrote:
> I'm new to QEMU and was able to pull the latest stable version and build it.
> I downloaded a simple test arm image that I found in one of the docs -
> arm-test-0.2.tar.gz and was able to run that w/o any problems.
Firstly, sorry that this has been a bit of a painful first
experience. You're right that the documentation online is
generally not very good and I'd like us to do better there.
One problem for ARM in particular is that QEMU has models of
a lot of different machines, which are generally very different.
So picking the right one can be confusing, especially if you're
used to x86 where every machine looks like a PC. ARM guest kernels
often won't work except on the machine they were built for.
For instance, the "integratorcp" machine you've been trying to
use is a very old development board (about 15 years old) and
it doesn't have PCI, IDE or very much memory. I wouldn't
recommend it unless you have a specific guest image which
you absolutely need to run on that particular board.
About the only machine model I can really solidly recommend is
"virt" -- this is the board used for running KVM virtual machines;
it doesn't correspond to any particular bit of real hardware
but it has the best support for PCI, lots of memory, etc.
The only slightly awkward part is that it doesn't have
graphics out of the box (you might be able to plug in an
emulated PCI graphics card but really it expects to be used
via serial console). If you want 64-bit ARM then "virt" is
pretty much the only sensible choice. I'd also recommend it
for 32-bit.
All the other boards I would suggest using only if you have
a specific positive reason to want to use that board rather
than "virt".
(I'll have a look to see if there's a good tutorial for
using the 'virt' board; we don't have any documentation for
it officially on the QEMU wiki, because mostly we just
provide the models of the hardware and leave it to other
people to provide the guest software.)
Some other suggestions:
For networking for simple development purposes,
the default "user mode" networking is fine, and
there's no need to try to set up bridge networking.
Bridge mode networking is really intended for serious
x86-based virtual machines where networking performance
is important, and I think most users there don't try to
configure it by hand but use a management layer like libvirt
to do the job. I've never bothered with setting up bridge
mode in the 6 years I've been working on QEMU.
If you don't give QEMU any networking arguments you should
get the 'user mode' networking. The only important points to
note are:
(1) 'ping' doesn't work, so don't try to use it as a test
(2) you can't directly connect from outside the VM to
inside it unless you set up a specific port redirection
on the QEMU command line. Connecting from inside the VM
to outside works fine, though.
For copying things into the VM I have two approaches:
(1) easiest is just to use 'scp' or similar inside the
VM to copy the file over the virtual network from the
host machine
(2) if there's a really huge amount of data, you can
shutdown the VM, and then loopback mount its filesystem
on the host PC to copy stuff in. Then unmount it from
the host before restarting the VM.
Other methods are also possible, but I've never needed to
investigate them.
The good news is that although this is an awkward "speed
bump" in learning to work with QEMU, you only have to get
over it once -- if you have a working setup it tends to
stay working. This is part of why the documentation isn't
great, I think most developers have some test images that they
got working years ago so they don't need to re-establish
them from scratch.
thanks
-- PMM
