Re: [Qemu-devel] [Qemu-arm] help on how to emulate rasbperry pi 2

[Andrew Baumann]

> From: John Snow [mailto:address@hidden
> Sent: Friday, 26 February 2016 9:13 AM
> 
> On 02/26/2016 04:30 AM, Mats Malmberg wrote:
> > Hello, thank you for your quick response!
> >
> > It helped me to get a little bit further, but unfortunately the problem
> persists.
> > I now get some output from the kernel startup, but I think that it is unable
> to find the provided sd-card image.
> >
> > Here's what I've tried (the most successful setup):
> > 1. download and deflate jessie/jessie-lite image (I tried both distros)
> > 2. mount the boot partition and copy the following files to host:
> kernel7.img, kernel.img and bcm2709-rpi-2-b.dtb
> > 3. mount the rootfs partition. Open the file /etc/ld.so.preload and
> comment out the line /usr/lib/arm-linux-gnueabihf/libarmmem.so (which is
> the only line present in the file.)
> > 4. execute the command
> > qemu-system-arm -M raspi2  -kernel kernel7.img -sd 2016-02-09-raspbian-
> jessie.img -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200
> dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -dtb bcm2709-rpi-2-b.dtb -
> serial stdio
> >
> > the resulting terminal printout :
> >
> > WARNING: Image format was not specified for '2016-02-09-raspbian-
> jessie.img' and probing guessed raw.
> >          Automatically detecting the format is dangerous for raw images, 
> > write
> operations on block 0 will be restricted.
> >          Specify the 'raw' format explicitly to remove the restrictions.
> > Warning: Orphaned drive without device: id=sd0,file=2016-02-09-raspbian-
> jessie.img,if=sd,bus=0,unit=0
> > VNC server running on '127.0.0.1;5900'
> > Uncompressing Linux... done, booting the kernel.
> > ...
> > lots of kernel output
> > ...
> > [    6.306894] sdhci-pltfm: SDHCI platform and OF driver helper
> > [    6.335521] ledtrig-cpu: registered to indicate activity on CPUs
> > [    6.338465] hidraw: raw HID events driver (C) Jiri Kosina
> > [    6.341004] usbcore: registered new interface driver usbhid
> > [    6.341768] usbhid: USB HID core driver
> > [    6.346873] Initializing XFRM netlink socket
> > [    6.348012] NET: Registered protocol family 17
> > [    6.350974] Key type dns_resolver registered
> > [    6.352810] Registering SWP/SWPB emulation handler
> > [    6.360245] registered taskstats version 1
> > [    6.374999] vc-sm: Videocore shared memory driver
> > [    6.397370] uart-pl011 3f201000.uart: no DMA platform data
> > [    6.428165] VFS: Cannot open root device "mmcblk0p2" or unknown-
> block(0,0): error -6
> > [    6.429208] Please append a correct "root=" boot option; here are the
> available partitions:
> > [    6.430848] 0100            4096 ram0  (driver?)
> > [    6.431718] 0101            4096 ram1  (driver?)
> > [    6.432348] 0102            4096 ram2  (driver?)
> > [    6.433101] 0103            4096 ram3  (driver?)
> > [    6.434627] 0104            4096 ram4  (driver?)
> > [    6.435317] 0105            4096 ram5  (driver?)
> > [    6.435995] 0106            4096 ram6  (driver?)
> > [    6.436749] 0107            4096 ram7  (driver?)
> > [    6.437507] 0108            4096 ram8  (driver?)
> > [    6.438159] 0109            4096 ram9  (driver?)
> > [    6.438853] 010a            4096 ram10  (driver?)
> > [    6.439562] 010b            4096 ram11  (driver?)
> > [    6.440193] 010c            4096 ram12  (driver?)
> > [    6.440815] 010d            4096 ram13  (driver?)
> > [    6.441439] 010e            4096 ram14  (driver?)
> > [    6.442065] 010f            4096 ram15  (driver?)
> > [    6.443003] Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
> > [    6.444949] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.1.17-v7+ #838
> > [    6.445837] Hardware name: BCM2709
> > [    6.448200] [<800180c0>] (unwind_backtrace) from [<80013b88>]
> (show_stack+0x20/0x24)
> > [    6.449477] [<80013b88>] (show_stack) from [<80555028>]
> (dump_stack+0x80/0x98)
> > [    6.450490] [<80555028>] (dump_stack) from [<80551540>]
> (panic+0xa4/0x204)
> > [    6.451641] [<80551540>] (panic) from [<80777384>]
> (mount_block_root+0x1a8/0x260)
> > [    6.452802] [<80777384>] (mount_block_root) from [<80777614>]
> (mount_root+0xec/0x110)
> > [    6.453878] [<80777614>] (mount_root) from [<807777a0>]
> (prepare_namespace+0x168/0x1c8)
> > [    6.454982] [<807777a0>] (prepare_namespace) from [<80776f90>]
> (kernel_init_freeable+0x270/0x2bc)
> > [    6.456243] [<80776f90>] (kernel_init_freeable) from [<80550968>]
> (kernel_init+0x18/0xfc)
> > [    6.457378] [<80550968>] (kernel_init) from [<8000f858>]
> (ret_from_fork+0x14/0x3c)
> > [    6.459706] ---[ end Kernel panic - not syncing: VFS: Unable to mount 
> > root
> fs on unknown-block(0,0)
> >
> > I know that in some of my previous attempts (before I contacted you
> guys), I was able to get similar result. At that time an mmcblk device was
> listed among the available partitions, but the kernel was unable to mount it.
> >
> > I'm having problem to identify the cause (since as I mentioned earlier this 
> > is
> not really my domain).
> > I've also tried (without any positive results)
> > - mark the boot partition as bootable with fdisk (does not seem to make
> any difference)
> > - use kernel.img instead of kernel7.img (does not provide any kernel
> printout, but still says that it has an orphaned drive and hangs indefinetly
> after saying VNC server running)
> > - create a image with 'qemu-img create raw jessie.img 4G' and use dd to
> copy original image into jessie.img file, and the provide qemu with
> format=raw.
> > - make the above qemu-system-arm invocation with -hda 2016-02-09-
> raspbian-jessie.img instead of -sd
> > - make the above qemu-system-arm invocation with -drive file=2016-02-
> 09-raspbian-jessie.img,format=raw,if=sd instead of -sd
> >
> >
> > Do you have any suggestions on how to proceed with my troubleshooting?
> > Are you able to explain what seems to be the problem (and possible
> cause)?
> >
> > Thank you for your help, really appreciated!
> >
> > Best regards
> > Mats
> >
> 
> Andrew, you might want to update the examples on that wiki: it looks
> like with recent changes that "-sd" was temporarily insufficient for
> getting a proper instance running.
> 
> Maybe you should also add some examples that use the -drive/-device
> combo that we canonically support in addition to the sugared -sd/-hda.
>
> Mats: for now, try grabbing the latest qemu master, it fixed a bug with
> -sd. :)

Yes, John's right, please try now and this bug should be fixed.

There was a regression in qemu-master for about a week, fixed by:
https://lists.nongnu.org/archive/html/qemu-devel/2016-02/msg05733.html

John, AFAIK there was no way to have working SD without this patch (the code to 
hook up the block device didn't exist), so I don't think there's much point 
updating the wiki.

Cheers,
Andrew