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

[John Snow <jsnow@redhat.com>]

On 02/26/2016 12:23 PM, Andrew Baumann wrote:
>> From: John Snow [mailto:jsnow@redhat.com]
>> 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
> 

`-drive if=none,id=sd0,file=etc.img,format=raw
 -device sd-card,drive=sd0,bus=sd-bus`

doesn't work?

The code to "hook up the block device" was added to the board init, but
that's for if=SD devices as added by -sd. the -drive/-device combo
should work anyway, because you are explicitly hooking it up via -device.

I guess the QOMification of SD is new, but usually we recommend/prefer
scripts and clients to use the explicit drive/device syntax above
instead of the -sd or -hda syntactic sugar. Real actual people can still
use -sd/-hd -- but they're prone to breakage as you've seen.

--js