Hi PMM, Thanks for a quick reply. Well if this is the case then I would stick to the NFS rootfs itself. Actually in the NFS case, the network bridge/tap that I have created is a bit scrappy. For eg., a file transfer runs for sometime and then halts for a minute or two, resulting in almost 8-10 times slower network access through QEMU as compared to my host machine. I guess this network behaviour is due to the reason that the same bridge is used load rootfs as well as do the file copy(or any other network related operation). That is the reason why I thought of switching to rootfs.img option. Is this network behaviour normal, or am I expecting too much ?
Thanks, Sid On Wed, Mar 16, 2011 at 6:07 PM, Peter Maydell <peter.mayd...@linaro.org>wrote: > On 16 March 2011 12:24, Sid Kapoor <sidkapoor2...@gmail.com> wrote: > > I am trying to run qemu after building rootfs.img as follows: > > > > $ qemu-system-arm -M realview-pbx-a9 -m 1024M -kernel zImage.rfs -serial > > stdio -append "root=/dev/hda1 rw console=ttyAMA0 rdinit=/sbin/init" -net > nic > > -net tap,ifname=tap0,script=no -hda rootfs.img > > > > But the issue I am facing is that there is no /dev/hda1 or similar device > > nodes in the qemu setup. > > This is because the PCI controller for the Realview PBX is not modelled > by QEMU, so there is no way to proivde an IDE or SCSI controller to the > guest. > > However, if you are willing to run qemu built from git (rather than > from a released version), there was support added very recently for > the SD card. This lets you run your image as an SD card image, by passing > '-sd rootfs.img' to qemu and using "root=/dev/mmcblk0p1" rather than > hda1. > > It's possible that the SD card approach may impose restrictions on > maximum size or alignment of the image which an hd image does not; > I haven't investigated. > > Hope this helps > -- PMM > -- Siddharth Kapoor Mobile - 9999169466
