Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Philippe Mathieu-Daudé]

Hey Zoltan,

On 8/20/19 4:50 PM, BALATON Zoltan wrote:
> On Tue, 15 Jan 2019, Philippe Mathieu-Daudé wrote:
>> On 1/15/19 7:29 PM, BALATON Zoltan wrote:
>>> On Thu, 29 Nov 2018, BALATON Zoltan wrote:
 Then I've tried the same with the pll patches posted by Philippe
 Mathieu-Daudé here:

 http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg00191.html

 on top of v3.1.0-rc3 which helped to get rid of the cprman warnings
>>>
>>> Will these patches be merged eventually? These seem to at least get rid
>>> of some annoying warnings in Linux boot dmesg.
>>
>> I'll respin this series addressing Peter's comments.
>>
>> Thanks for reminding me ;)
>>
>> Phil.
> 
> While you're at raspi patches maybe I remind you again of the above :-)
> I think I haven't seen these being merged yet but correct me if I'm wrong.

You are correct :)

I did address the issue reported by Peter regarding the CPRMAN block.

Guenter tried the series and reported issue with the A2W block (he did
implement it, basically to return 0x10001 for a pair of registers, but I
hadn't implemented it).

Now I have a basic A2W implemented, but I can't reproduce the error
Guenter reported, so I was waiting for more spare time to invest on
this. Anyhow meanwhile I can post my work as RFC.

Regards,

Phil.

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[BALATON Zoltan]

Hello Philippe,

On Tue, 15 Jan 2019, Philippe Mathieu-Daudé wrote:

On 1/15/19 7:29 PM, BALATON Zoltan wrote:

On Thu, 29 Nov 2018, BALATON Zoltan wrote:

Then I've tried the same with the pll patches posted by Philippe
Mathieu-Daudé here:

http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg00191.html

on top of v3.1.0-rc3 which helped to get rid of the cprman warnings


Will these patches be merged eventually? These seem to at least get rid
of some annoying warnings in Linux boot dmesg.


I'll respin this series addressing Peter's comments.

Thanks for reminding me ;)

Phil.


While you're at raspi patches maybe I remind you again of the above :-)
I think I haven't seen these being merged yet but correct me if I'm wrong.

Regards,
BALATON Zoltan

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[BALATON Zoltan]

Hello,

On Tue, 15 Jan 2019, Philippe Mathieu-Daudé wrote:

On 1/15/19 7:29 PM, BALATON Zoltan wrote:

On Thu, 29 Nov 2018, BALATON Zoltan wrote:

Then I've tried the same with the pll patches posted by Philippe
Mathieu-Daudé here:

http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg00191.html

on top of v3.1.0-rc3 which helped to get rid of the cprman warnings


Will these patches be merged eventually? These seem to at least get rid
of some annoying warnings in Linux boot dmesg.


I'll respin this series addressing Peter's comments.

Thanks for reminding me ;)


What happened to these? Will they make it in master before the freeze?

Regards,
BALATON Zoltan

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[BALATON Zoltan]

On Mon, 28 Jan 2019, Peter Maydell wrote:

On Sun, 27 Jan 2019 at 23:13, BALATON Zoltan  wrote:

On Sun, 27 Jan 2019, Peter Maydell wrote:

Unfortunately I'm not sufficiently familiar with how OSX
event handling works to figure out how to plumb it back in
again. It ought to be a fairly simple matter of "implement
whatever method OSX sends events to on whatever of our
various classes is the right one, and make it call handleEvent
with the NSEvent", but I've tried a few things and haven't
been able to actually get any event handling methods to
fire at all :-(


I think you need to implement keyDown: and keyUp: methods in QemuCocoaView
to get keyboard events and there are similar methods for mouse events,
see:

https://developer.apple.com/documentation/appkit/nsview?language=objc


Yeah, I got something working later last night. You also need
to implement acceptsFirstResponder or you don't get any events.


Yes, I remembered it also has something to do with FirstResponder but did 
not recall what you need for it.



So I have something that at least works for key events in the
monitor window now. I need to check whether we do the right
thing for things like cmd-key hotkeys which need to be handled
by the stock OSX event handling. (In the old scheme we deal with
these by having handleEvent pass them on to sendEvent, but in
the new setup that's an infinite recursion.)


But these are a lot of methods which are supposedly called from the
sendEvent: method of the NSWindow containing this view so maybe a better
place to catch all events is there. For this we need an NSWindow subclass
implementing sendEvent: which is then used to hold QemuCocoaView. I may be
wrong though, haven't tested it and don't know what you've tried.


Yeah, we could also do something like that, or another approach
I found by searching around is to use addLocalMonitorForEventsMatchingMask
to catch events. I'd kind of prefer to do whatever is the "expected"
setup for OSX apps, though, and I get the impression that completely
overriding sendEvent is a bit outside the normal path.


Event monitor is also an option on 10.6+ (which we already require I 
think). Not sure if it's simpler. Overriding sendEvent: is mentioned in 
the docs so probably it should be OK and as long as you pass all unhandled 
events to the super method it also should not break to much. I think 
command key actions are handled at the NSApp level so if we override at 
the NSWindow level then probably we don't have to care about those but I'm 
not completely sure.


Regards,
BALATON Zoltan

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Peter Maydell]

On Sun, 27 Jan 2019 at 23:13, BALATON Zoltan  wrote:
> On Sun, 27 Jan 2019, Peter Maydell wrote:
> > Unfortunately I'm not sufficiently familiar with how OSX
> > event handling works to figure out how to plumb it back in
> > again. It ought to be a fairly simple matter of "implement
> > whatever method OSX sends events to on whatever of our
> > various classes is the right one, and make it call handleEvent
> > with the NSEvent", but I've tried a few things and haven't
> > been able to actually get any event handling methods to
> > fire at all :-(
>
> I think you need to implement keyDown: and keyUp: methods in QemuCocoaView
> to get keyboard events and there are similar methods for mouse events,
> see:
>
> https://developer.apple.com/documentation/appkit/nsview?language=objc

Yeah, I got something working later last night. You also need
to implement acceptsFirstResponder or you don't get any events.
So I have something that at least works for key events in the
monitor window now. I need to check whether we do the right
thing for things like cmd-key hotkeys which need to be handled
by the stock OSX event handling. (In the old scheme we deal with
these by having handleEvent pass them on to sendEvent, but in
the new setup that's an infinite recursion.)

> But these are a lot of methods which are supposedly called from the
> sendEvent: method of the NSWindow containing this view so maybe a better
> place to catch all events is there. For this we need an NSWindow subclass
> implementing sendEvent: which is then used to hold QemuCocoaView. I may be
> wrong though, haven't tested it and don't know what you've tried.

Yeah, we could also do something like that, or another approach
I found by searching around is to use addLocalMonitorForEventsMatchingMask
to catch events. I'd kind of prefer to do whatever is the "expected"
setup for OSX apps, though, and I get the impression that completely
overriding sendEvent is a bit outside the normal path.

thanks
-- PMM

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[BALATON Zoltan]

On Sun, 27 Jan 2019, Peter Maydell wrote:

On Wed, 19 Dec 2018 at 19:42, Ben Hekster  wrote:


Should have tested a little more:

While the crashing has stopped, the window isn't responsive to
keystrokes.  This includes the frame buffer emulation itself (so
I can't actually log in) as well as the QEMU Monitor; nothing I
type has any effect in either.


Yes, I can reproduce this with my "refactor the OSX UI code"
patchset too. The problem is that with the removal of the
code that was in the cocoa_refresh() function that manually
pulled events out of the OSX event queue and called our
QemuCocoaView handleEvent method on them, there's nothing
that does cause that code to be called. (I had mistakenly
assumed handleEvent was an OSX UI method and so the run loop
would call it.)

Unfortunately I'm not sufficiently familiar with how OSX
event handling works to figure out how to plumb it back in
again. It ought to be a fairly simple matter of "implement
whatever method OSX sends events to on whatever of our
various classes is the right one, and make it call handleEvent
with the NSEvent", but I've tried a few things and haven't
been able to actually get any event handling methods to
fire at all :-(


I think you need to implement keyDown: and keyUp: methods in QemuCocoaView 
to get keyboard events and there are similar methods for mouse events, 
see:


https://developer.apple.com/documentation/appkit/nsview?language=objc

But these are a lot of methods which are supposedly called from the 
sendEvent: method of the NSWindow containing this view so maybe a better 
place to catch all events is there. For this we need an NSWindow subclass 
implementing sendEvent: which is then used to hold QemuCocoaView. I may be 
wrong though, haven't tested it and don't know what you've tried. (If all 
else fails there's also sendEvent: of NSApp which is where all events 
should start from and it might be subclassed as well but then some events 
may need to be passed on so doing it at the window is probably better.)


Regards,
BALATON Zoltan

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Peter Maydell]

On Wed, 19 Dec 2018 at 19:42, Ben Hekster  wrote:
>
> Should have tested a little more:
>
> While the crashing has stopped, the window isn't responsive to
>keystrokes.  This includes the frame buffer emulation itself (so
>I can't actually log in) as well as the QEMU Monitor; nothing I
>type has any effect in either.

Yes, I can reproduce this with my "refactor the OSX UI code"
patchset too. The problem is that with the removal of the
code that was in the cocoa_refresh() function that manually
pulled events out of the OSX event queue and called our
QemuCocoaView handleEvent method on them, there's nothing
that does cause that code to be called. (I had mistakenly
assumed handleEvent was an OSX UI method and so the run loop
would call it.)

Unfortunately I'm not sufficiently familiar with how OSX
event handling works to figure out how to plumb it back in
again. It ought to be a fairly simple matter of "implement
whatever method OSX sends events to on whatever of our
various classes is the right one, and make it call handleEvent
with the NSEvent", but I've tried a few things and haven't
been able to actually get any event handling methods to
fire at all :-(

thanks
-- PMM

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Philippe Mathieu-Daudé]

On 1/15/19 7:29 PM, BALATON Zoltan wrote:
> On Thu, 29 Nov 2018, BALATON Zoltan wrote:
>> Then I've tried the same with the pll patches posted by Philippe
>> Mathieu-Daudé here:
>>
>> http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg00191.html
>>
>> on top of v3.1.0-rc3 which helped to get rid of the cprman warnings
> 
> Will these patches be merged eventually? These seem to at least get rid
> of some annoying warnings in Linux boot dmesg.

I'll respin this series addressing Peter's comments.

Thanks for reminding me ;)

Phil.

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[BALATON Zoltan]

On Thu, 29 Nov 2018, BALATON Zoltan wrote:
Then I've tried the same with the pll patches posted by Philippe 
Mathieu-Daudé here:


http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg00191.html

on top of v3.1.0-rc3 which helped to get rid of the cprman warnings


Will these patches be merged eventually? These seem to at least get rid of 
some annoying warnings in Linux boot dmesg.


Regards,
BALATON Zoltan

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[BALATON Zoltan]

On Wed, 19 Dec 2018, Ben Hekster via Qemu-devel wrote:
	While the crashing has stopped, the window isn't responsive to 
keystrokes.  This includes the frame buffer emulation itself (so I can't 
actually log in)


I'm not sure that's supposed to work. I could be wrong but I think USB is 
not emulated yet so likely no keyboard is attached that you could type 
with. The framebuffer is emulated so you can see output but only way to 
input is via serial if I'm not mistaken. That's what works for me.



as well as the QEMU Monitor; nothing I type has any effect in either.


The monitor view should work though. Does it work without the patches? If 
you start with "qemu-system-arm -M raspi2 -S" you can probably try it 
before it crashes.


Regards,
BALATON Zoltan

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Ben Hekster via Qemu-devel]

Should have tested a little more:

While the crashing has stopped, the window isn't responsive to 
keystrokes.  This includes the frame buffer emulation itself (so I can't 
actually log in) as well as the QEMU Monitor; nothing I type has any effect in 
either.

Ben

> On Dec 19, 2018, at 11:36, Ben Hekster  wrote:
> 
> Checked out tag patchew/20181201123056.432-1-peter.mayd...@linaro.org 
>  from 
> https://github.com/patchew-project/qemu 
>  and verified the crash no longer 
> occurs.  It does indeed appear that the crash previously happened right 
> around the time where I can now see the window being resized.
> 
> I've attached a screenshot here for you; not sure if this will make it 
> through to the mailing list...
> 
> Ben
> 
>> On Dec 19, 2018, at 10:43, Peter Maydell > > wrote:
>> 
>> On Wed, 19 Dec 2018 at 17:46, Ben Hekster > > wrote:
>>> probably a manifestation of https://bugs.launchpad.net/qemu/+bug/1802684 
>>> 
>> Yep. If you could test the patchset at
>> http://patchew.org/QEMU/20181201123056.432-1-peter.mayd...@linaro.org/ 
>> 
>> and confirm that it fixes the problem that would be great.
>> 
>> thanks
>> -- PMM
> 
> 

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Ben Hekster via Qemu-devel]

Checked out tag patchew/20181201123056.432-1-peter.mayd...@linaro.org from 
https://github.com/patchew-project/qemu and verified the crash no longer 
occurs.  It does indeed appear that the crash previously happened right around 
the time where I can now see the window being resized.

I've attached a screenshot here for you; not sure if this will make it through 
to the mailing list...

Ben

> On Dec 19, 2018, at 10:43, Peter Maydell  wrote:
> 
> On Wed, 19 Dec 2018 at 17:46, Ben Hekster  wrote:
>> probably a manifestation of https://bugs.launchpad.net/qemu/+bug/1802684
> 
> Yep. If you could test the patchset at
> http://patchew.org/QEMU/20181201123056.432-1-peter.mayd...@linaro.org/
> and confirm that it fixes the problem that would be great.
> 
> thanks
> -- PMM

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Peter Maydell]

On Wed, 19 Dec 2018 at 17:46, Ben Hekster  wrote:
> Stack trace of crashing thread:

Thank you.

> 21  AppKit  0x7fff3280e99e -[NSWindow 
> setFrame:display:] + 51
> 22  AppKit  0x7fff3281932f -[NSWindow 
> setFrame:display:animate:] + 130
> 23  qemu-system-arm 0x0001035cb13a -[QemuCocoaView 
> switchSurface:] + 2282
> 24  qemu-system-arm 0x0001035d102e cocoa_switch + 94
> 25  qemu-system-arm 0x0001035bfa46 
> dpy_gfx_replace_surface + 278
> 26  qemu-system-arm 0x0001035c1721 
> qemu_console_resize + 209
> 27  qemu-system-arm 0x00010310be80 
> bcm2835_fb_reconfigure + 112

OK, so this is what I suspected we might be doing -- certain functions called
from device emulation (so on the CPU thread) end up calling in to the cocoa
UI DisplayChangeListenerOps callbacks, which at the moment are written
to directly call OSX functions. But only certain guest behaviour (in this
instance a guest resizing the display) causes this, so a lot of guest
use cases will work OK even on Mojave.

> probably a manifestation of https://bugs.launchpad.net/qemu/+bug/1802684

Yep. If you could test the patchset at
http://patchew.org/QEMU/20181201123056.432-1-peter.mayd...@linaro.org/
and confirm that it fixes the problem that would be great.

thanks
-- PMM

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Ben Hekster via Qemu-devel]

> On Dec 19, 2018, at 05:17, Peter Maydell  wrote:
> 
> 
> OSX works for me, though I don't test it thoroughly. If you
> are getting a crash that you can reproduce, please could
> you repro it under a debugger with a debug build of QEMU
> and send the all-threads backtrace for the crash?
> 
> thanks
> -- PMM

Still reproducible with current master on OS X Mojave 10.14.1.  Command line:

$ arm-softmmu/qemu-system-arm -M raspi2 -append "console=ttyAMA0,115200 
root=/dev/mmcblk0p2 rootwait rw" -cpu cortex-a7 -dtb bcm2709-rpi-2-b.dtb -drive 
file=2018-11-13-raspbian-stretch-lite.img,if=sd,format=raw -kernel kernel7.img 
-m 256m -no-reboot

Stack trace of crashing thread:

2018-12-19 09:33:01.348 qemu-system-arm[93254:2731556] *** Terminating app due 
to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow 
drag regions should only be invalidated on the Main Thread!'
*** First throw call stack:
(
0   CoreFoundation  0x7fff35291e65 
__exceptionPreprocess + 256
1   libobjc.A.dylib 0x7fff612ed720 
objc_exception_throw + 48
2   CoreFoundation  0x7fff352ab8e5 
-[NSException raise] + 9
3   AppKit  0x7fff327b07e6 
-[NSWindow(NSWindow_Theme) 
_postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 324
4   AppKit  0x7fff327b5c40 -[NSView 
setFrameSize:] + 2082
5   AppKit  0x7fff32826975 
-[NSVisualEffectView setFrameSize:] + 171
6   AppKit  0x7fff328806a5 
-[NSTitlebarView setFrameSize:] + 84
7   AppKit  0x7fff327b4c49 -[NSView 
setFrame:] + 478
8   AppKit  0x7fff32880648 
-[NSTitlebarView resizeWithOldSuperviewSize:] + 100
9   AppKit  0x7fff327bbde6 -[NSView 
resizeSubviewsWithOldSize:] + 502
10  AppKit  0x7fff327b5ac9 -[NSView 
setFrameSize:] + 1707
11  AppKit  0x7fff3317604c 
-[NSTitlebarContainerView setFrameSize:] + 142
12  AppKit  0x7fff327b4c49 -[NSView 
setFrame:] + 478
13  AppKit  0x7fff327bc23d -[NSView 
resizeWithOldSuperviewSize:] + 776
14  AppKit  0x7fff327bbde6 -[NSView 
resizeSubviewsWithOldSize:] + 502
15  AppKit  0x7fff327b5ac9 -[NSView 
setFrameSize:] + 1707
16  AppKit  0x7fff32823a5e 
-[NSThemeFrame setFrameSize:] + 495
17  AppKit  0x7fff3281070b -[NSWindow 
_setFrame:updateBorderViewSize:] + 966
18  AppKit  0x7fff3281002e -[NSWindow 
_oldPlaceWindow:] + 547
19  AppKit  0x7fff3280f639 -[NSWindow 
_setFrameCommon:display:stashSize:] + 3006
20  AppKit  0x7fff3280ea65 -[NSWindow 
_setFrame:display:allowImplicitAnimation:stashSize:] + 192
21  AppKit  0x7fff3280e99e -[NSWindow 
setFrame:display:] + 51
22  AppKit  0x7fff3281932f -[NSWindow 
setFrame:display:animate:] + 130
23  qemu-system-arm 0x0001035cb13a 
-[QemuCocoaView switchSurface:] + 2282
24  qemu-system-arm 0x0001035d102e cocoa_switch 
+ 94
25  qemu-system-arm 0x0001035bfa46 
dpy_gfx_replace_surface + 278
26  qemu-system-arm 0x0001035c1721 
qemu_console_resize + 209
27  qemu-system-arm 0x00010310be80 
bcm2835_fb_reconfigure + 112
28  qemu-system-arm 0x00010315a65c 
bcm2835_property_mbox_push + 4156
29  qemu-system-arm 0x000103159584 
bcm2835_property_write + 148
30  qemu-system-arm 0x000103097cf3 
memory_region_write_accessor + 243
31  qemu-system-arm 0x000103097bd6 
access_with_adjusted_size + 454
32  qemu-system-arm 0x000103097702 
memory_region_dispatch_write + 258
33  qemu-system-arm 0x00010301bb84 
address_space_stl_internal + 212
34  qemu-system-arm 0x00010301bca7 
address_space_stl_le + 55
35  qemu-system-arm 0x000103158fd4 stl_le_phys 
+ 84
36  qemu-system-arm 0x000103158a6c 
bcm2835_mbox_write + 428
37  qemu-system-arm 0x000103097cf3 
memory_region_write_accessor + 243
38  qemu-system-arm 0x000103097bd6 
access_with_adjusted_size + 454

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Peter Maydell]

On Tue, 18 Dec 2018 at 21:57, Ben Hekster via Qemu-devel
 wrote:
> Did it for me using stock QEMU 3.1.0.  (I need "-nographic"
> because the OS X port crashes without it)

OSX works for me, though I don't test it thoroughly. If you
are getting a crash that you can reproduce, please could
you repro it under a debugger with a debug build of QEMU
and send the all-threads backtrace for the crash?

thanks
-- PMM

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[BALATON Zoltan]

On Tue, 18 Dec 2018, Ben Hekster via Qemu-devel wrote:

I had the exact same issue; for me it was just the addition of Günther's 
"rootwait" option that resolved it, so:

$ qemu-system-arm \
-m 256m \
-M raspi2 \
-cpu cortex-a7 \
-append "console=ttyAMA0,115200 root=/dev/mmcblk0p2 rootwait rw" \
-dtb bcm2709-rpi-2-b.dtb \
-drive file=2018-11-13-raspbian-stretch-lite.img,if=sd,format=raw \
-kernel kernel7.img \
-nographic

Did it for me using stock QEMU 3.1.0.  (I need "-nographic" because the OS X 
port crashes without it)


Indeed. Thanks. It also boots with the raspbian kernel7.img after adding 
this option, so likely the cause of this was that mmc wasn't detected fast 
enough and without rootwait it tried to mount it without waiting before 
it was available.


It does not crash on OS X for me even without -nographic but I'm not yet 
on Mojave. I've read there may be problems on latest macOS and seen 
patches to fix that. Here's the discussion:


https://bugs.launchpad.net/qemu/+bug/1802684

Launchpad seems to have eaten the RFC patch URL in the last comment but I 
think it's this one:


http://patchew.org/QEMU/20181201123056.432-1-peter.mayd...@linaro.org/

Maybe you can test and report back if this fixes your problem so it can be 
merged if it helps.


Thank you,
BALATON Zoltan

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Ben Hekster via Qemu-devel]

Hi, Zoltan—

> On Thu, 29 Nov 2018, Guenter Roeck wrote:
> On 11/29/18 6:42 PM, BALATON Zoltan wrote:
> On Thu, 29 Nov 2018, Guenter Roeck wrote:
> On 11/29/18 4:43 PM, Philippe Mathieu-Daudé wrote:
> Hi Zoltan,
> 
> On 29/11/18 21:29, BALATON Zoltan wrote:
> Hello,
> 
> I could not boot Raspbian on QEMU's raspi emulation and I'm not sure why
> it fails. So question is if this is supposed to work or am I doing
> something wrong or any clues what may be missing? I'm trying with this
> command line with v3.1.0-rc3:
> 
> qemu-system-arm -M raspi2 -serial stdio \
> -kernel rpi-kernel7.img -dtb bcm2709-rpi-2-b.dtb \
> -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200
> dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" \
> -drive file=2018-10-09-raspbian-stretch-lite.img,format=raw,if=sd
> 
> Kernel starts to boot, I see raspberries on the guest screen and log
> output to serial:
> 
> Booting Linux on physical CPU 0xf00
> Linux version 4.14.71-v7+ (address@hidden) (gcc version 4.9.3
> (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1145 SMP Fri Sep 21
> 15:38:35 BST 2018
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> [...]
> 
> My version (https://github.com/groeck/qemu ) 
> seems to work, using
> Tried with your v3.1.0-local branch but got same results (does not find 
> mmcblk0 on raspi2, nothing on raspi3) so probably it's not one of the patches 
> in your tree that's missing.
> multi_v7_defconfig.
> Then maybe it's your kernel config that's different? Do you have compiled 
> kernels available that I could try?
> Shouldn't be, but I attached my configuration. This time with v4.14.84 and
> "make ARCH-arm savedefconfig" after building the image. The output is 
> identical
> to "make ARCH=arm multi_v7_defconfig; make ARCH=arm savedefconfig".
> 
> Oh, and here is my qemu configuration.
> 
> --disable-user --disable-gnutls --disable-docs \
>--disable-nettle --disable-gcrypt --disable-vnc-png \
>--disable-xen --disable-xen-pci-passthrough \
>--enable-debug --disable-strip
> 
> That should not make a difference either, but who knows.
> Just to be sure, I copied a kernel and a root file system
> to http://server.roeck-us.net/qemu/arm-raspi2/ 
> 
> It boots with your kernel (also the raspbian-lite image) so it's likely that 
> the config of the Raspbian kernel is different and that causes the problem. 
> Unfortunately I don't know what config their kernels use. If I'm not mistaken 
> this is the raspbian kernel repo:
> https://github.com/raspberrypi/linux/ 
> 
> My guesses would be bcm2835_defconfig or some other bcm*config? Or something 
> completely different?
> Regards,
> BALATON Zoltan

I had the exact same issue; for me it was just the addition of Günther's 
"rootwait" option that resolved it, so:

$ qemu-system-arm \
-m 256m \
-M raspi2 \
-cpu cortex-a7 \
-append "console=ttyAMA0,115200 root=/dev/mmcblk0p2 rootwait rw" \
-dtb bcm2709-rpi-2-b.dtb \
-drive file=2018-11-13-raspbian-stretch-lite.img,if=sd,format=raw \
-kernel kernel7.img \
-nographic

Did it for me using stock QEMU 3.1.0.  (I need "-nographic" because the OS X 
port crashes without it)

Ben

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[BALATON Zoltan]

On Thu, 29 Nov 2018, Guenter Roeck wrote:

On 11/29/18 6:42 PM, BALATON Zoltan wrote:

On Thu, 29 Nov 2018, Guenter Roeck wrote:

On 11/29/18 4:43 PM, Philippe Mathieu-Daudé wrote:

Hi Zoltan,

On 29/11/18 21:29, BALATON Zoltan wrote:

Hello,

I could not boot Raspbian on QEMU's raspi emulation and I'm not sure why
it fails. So question is if this is supposed to work or am I doing
something wrong or any clues what may be missing? I'm trying with this
command line with v3.1.0-rc3:

qemu-system-arm -M raspi2 -serial stdio \
-kernel rpi-kernel7.img -dtb bcm2709-rpi-2-b.dtb \
-append "rw earlyprintk loglevel=8 console=ttyAMA0,115200
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" \
-drive file=2018-10-09-raspbian-stretch-lite.img,format=raw,if=sd

Kernel starts to boot, I see raspberries on the guest screen and log
output to serial:

Booting Linux on physical CPU 0xf00
Linux version 4.14.71-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3
(crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1145 SMP Fri Sep 21
15:38:35 BST 2018
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[...]





My version (https://github.com/groeck/qemu) seems to work, using


Tried with your v3.1.0-local branch but got same results (does not find 
mmcblk0 on raspi2, nothing on raspi3) so probably it's not one of the 
patches in your tree that's missing.



multi_v7_defconfig.


Then maybe it's your kernel config that's different? Do you have compiled 
kernels available that I could try?




Shouldn't be, but I attached my configuration. This time with v4.14.84 and
"make ARCH-arm savedefconfig" after building the image. The output is 
identical

to "make ARCH=arm multi_v7_defconfig; make ARCH=arm savedefconfig".

Oh, and here is my qemu configuration.

--disable-user --disable-gnutls --disable-docs \
   --disable-nettle --disable-gcrypt --disable-vnc-png \
   --disable-xen --disable-xen-pci-passthrough \
   --enable-debug --disable-strip

That should not make a difference either, but who knows.
Just to be sure, I copied a kernel and a root file system
to http://server.roeck-us.net/qemu/arm-raspi2/


It boots with your kernel (also the raspbian-lite image) so it's likely 
that the config of the Raspbian kernel is different and that causes the 
problem. Unfortunately I don't know what config their kernels use. If I'm 
not mistaken this is the raspbian kernel repo:


https://github.com/raspberrypi/linux/

My guesses would be bcm2835_defconfig or some other bcm*config? Or 
something completely different?


Regards,
BALATON Zoltan

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Guenter Roeck]

On 11/29/18 6:42 PM, BALATON Zoltan wrote:

On Thu, 29 Nov 2018, Guenter Roeck wrote:

On 11/29/18 4:43 PM, Philippe Mathieu-Daudé wrote:

Hi Zoltan,

On 29/11/18 21:29, BALATON Zoltan wrote:

Hello,

I could not boot Raspbian on QEMU's raspi emulation and I'm not sure why
it fails. So question is if this is supposed to work or am I doing
something wrong or any clues what may be missing? I'm trying with this
command line with v3.1.0-rc3:

qemu-system-arm -M raspi2 -serial stdio \
-kernel rpi-kernel7.img -dtb bcm2709-rpi-2-b.dtb \
-append "rw earlyprintk loglevel=8 console=ttyAMA0,115200
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" \
-drive file=2018-10-09-raspbian-stretch-lite.img,format=raw,if=sd

Kernel starts to boot, I see raspberries on the guest screen and log
output to serial:

Booting Linux on physical CPU 0xf00
Linux version 4.14.71-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3
(crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1145 SMP Fri Sep 21
15:38:35 BST 2018
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[...]





My version (https://github.com/groeck/qemu) seems to work, using


Tried with your v3.1.0-local branch but got same results (does not find mmcblk0 
on raspi2, nothing on raspi3) so probably it's not one of the patches in your 
tree that's missing.


multi_v7_defconfig.


Then maybe it's your kernel config that's different? Do you have compiled 
kernels available that I could try?



Shouldn't be, but I attached my configuration. This time with v4.14.84 and
"make ARCH-arm savedefconfig" after building the image. The output is identical
to "make ARCH=arm multi_v7_defconfig; make ARCH=arm savedefconfig".

Oh, and here is my qemu configuration.

--disable-user --disable-gnutls --disable-docs \
--disable-nettle --disable-gcrypt --disable-vnc-png \
--disable-xen --disable-xen-pci-passthrough \
--enable-debug --disable-strip

That should not make a difference either, but who knows.
Just to be sure, I copied a kernel and a root file system
to http://server.roeck-us.net/qemu/arm-raspi2/

Hope it helps.

Guenter
CONFIG_SYSVIPC=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_CMDLINE_PARTITION=y
CONFIG_ARCH_VIRT=y
CONFIG_ARCH_MVEBU=y
CONFIG_MACH_ARMADA_370=y
CONFIG_MACH_ARMADA_375=y
CONFIG_MACH_ARMADA_38X=y
CONFIG_MACH_ARMADA_39X=y
CONFIG_MACH_ARMADA_XP=y
CONFIG_MACH_DOVE=y
CONFIG_ARCH_ALPINE=y
CONFIG_ARCH_ARTPEC=y
CONFIG_MACH_ARTPEC6=y
CONFIG_ARCH_AT91=y
CONFIG_SOC_SAMA5D2=y
CONFIG_SOC_SAMA5D3=y
CONFIG_SOC_SAMA5D4=y
CONFIG_ARCH_BCM=y
CONFIG_ARCH_BCM_CYGNUS=y
CONFIG_ARCH_BCM_NSP=y
CONFIG_ARCH_BCM_5301X=y
CONFIG_ARCH_BCM_281XX=y
CONFIG_ARCH_BCM_21664=y
CONFIG_ARCH_BCM2835=y
CONFIG_ARCH_BCM_63XX=y
CONFIG_ARCH_BRCMSTB=y
CONFIG_ARCH_BERLIN=y
CONFIG_MACH_BERLIN_BG2=y
CONFIG_MACH_BERLIN_BG2CD=y
CONFIG_MACH_BERLIN_BG2Q=y
CONFIG_ARCH_DIGICOLOR=y
CONFIG_ARCH_HIGHBANK=y
CONFIG_ARCH_HISI=y
CONFIG_ARCH_HI3xxx=y
CONFIG_ARCH_HIP01=y
CONFIG_ARCH_HIP04=y
CONFIG_ARCH_HIX5HD2=y
CONFIG_ARCH_KEYSTONE=y
CONFIG_ARCH_MESON=y
CONFIG_ARCH_MXC=y
CONFIG_SOC_IMX50=y
CONFIG_SOC_IMX51=y
CONFIG_SOC_IMX53=y
CONFIG_SOC_IMX6Q=y
CONFIG_SOC_IMX6SL=y
CONFIG_SOC_IMX6SX=y
CONFIG_SOC_IMX6UL=y
CONFIG_SOC_IMX7D=y
CONFIG_SOC_LS1021A=y
CONFIG_SOC_VF610=y
CONFIG_ARCH_MEDIATEK=y
CONFIG_ARCH_OMAP3=y
CONFIG_ARCH_OMAP4=y
CONFIG_SOC_OMAP5=y
CONFIG_SOC_AM33XX=y
CONFIG_SOC_AM43XX=y
CONFIG_SOC_DRA7XX=y
CONFIG_ARCH_QCOM=y
CONFIG_ARCH_MSM8X60=y
CONFIG_ARCH_MSM8960=y
CONFIG_ARCH_MSM8974=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_ARCH_SOCFPGA=y
CONFIG_PLAT_SPEAR=y
CONFIG_ARCH_SPEAR13XX=y
CONFIG_MACH_SPEAR1310=y
CONFIG_MACH_SPEAR1340=y
CONFIG_ARCH_STI=y
CONFIG_ARCH_EXYNOS=y
CONFIG_EXYNOS5420_MCPM=y
CONFIG_ARCH_RENESAS=y
CONFIG_ARCH_EMEV2=y
CONFIG_ARCH_R7S72100=y
CONFIG_ARCH_R8A73A4=y
CONFIG_ARCH_R8A7740=y
CONFIG_ARCH_R8A7743=y
CONFIG_ARCH_R8A7745=y
CONFIG_ARCH_R8A7778=y
CONFIG_ARCH_R8A7779=y
CONFIG_ARCH_R8A7790=y
CONFIG_ARCH_R8A7791=y
CONFIG_ARCH_R8A7792=y
CONFIG_ARCH_R8A7793=y
CONFIG_ARCH_R8A7794=y
CONFIG_ARCH_SH73A0=y
CONFIG_ARCH_SUNXI=y
CONFIG_ARCH_SIRF=y
CONFIG_ARCH_TEGRA=y
CONFIG_ARCH_UNIPHIER=y
CONFIG_ARCH_U8500=y
CONFIG_MACH_HREFV60=y
CONFIG_MACH_SNOWBALL=y
CONFIG_ARCH_VEXPRESS=y
CONFIG_ARCH_VEXPRESS_TC2_PM=y
CONFIG_ARCH_WM8850=y
CONFIG_ARCH_ZYNQ=y
CONFIG_PCI_KEYSTONE=y
CONFIG_PCI_MVEBU=y
CONFIG_PCI_TEGRA=y
CONFIG_PCI_RCAR_GEN2=y
CONFIG_PCIE_RCAR=y
CONFIG_SMP=y
CONFIG_NR_CPUS=16
CONFIG_CMA=y
CONFIG_SECCOMP=y
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_KEXEC=y
CONFIG_EFI=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
CONFIG_CPUFREQ_DT=y
CONFIG_ARM_IMX6Q_CPUFREQ=y
CONFIG_QORIQ_CPUFREQ=y
CONFIG_CPU_IDLE=y
CONFIG_ARM_CPUIDLE=y
CONFIG_ARM_ZYNQ_CPUIDLE=y

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[BALATON Zoltan]

On Thu, 29 Nov 2018, Guenter Roeck wrote:

On 11/29/18 4:43 PM, Philippe Mathieu-Daudé wrote:

Hi Zoltan,

On 29/11/18 21:29, BALATON Zoltan wrote:

Hello,

I could not boot Raspbian on QEMU's raspi emulation and I'm not sure why
it fails. So question is if this is supposed to work or am I doing
something wrong or any clues what may be missing? I'm trying with this
command line with v3.1.0-rc3:

qemu-system-arm -M raspi2 -serial stdio \
-kernel rpi-kernel7.img -dtb bcm2709-rpi-2-b.dtb \
-append "rw earlyprintk loglevel=8 console=ttyAMA0,115200
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" \
-drive file=2018-10-09-raspbian-stretch-lite.img,format=raw,if=sd

Kernel starts to boot, I see raspberries on the guest screen and log
output to serial:

Booting Linux on physical CPU 0xf00
Linux version 4.14.71-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3
(crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1145 SMP Fri Sep 21
15:38:35 BST 2018
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[...]





My version (https://github.com/groeck/qemu) seems to work, using


Tried with your v3.1.0-local branch but got same results (does not find 
mmcblk0 on raspi2, nothing on raspi3) so probably it's not one of the 
patches in your tree that's missing.



multi_v7_defconfig.


Then maybe it's your kernel config that's different? Do you have compiled 
kernels available that I could try?


Thank you,
BALATON Zoltan


Logs from boots with qemu 3.0 and 3.1 attached.

Command line:

/opt/buildbot/qemu-install/v3.0/bin/qemu-system-arm \
-M raspi2 -kernel arch/arm/boot/zImage -no-reboot \
	-snapshot -drive 
file=core-image-minimal-qemuarm.ext3,format=raw,if=sd \
	--append 'earlycon=pl011,0x3f201000 root=/dev/mmcblk0 rootwait rw 
console=ttyAMA0 noreboot' \

-dtb arch/arm/boot/dts/bcm2836-rpi-2-b.dtb \
-nographic -monitor null -serial stdio

Guenter

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Guenter Roeck]

On 11/29/18 4:43 PM, Philippe Mathieu-Daudé wrote:

Hi Zoltan,

On 29/11/18 21:29, BALATON Zoltan wrote:

Hello,

I could not boot Raspbian on QEMU's raspi emulation and I'm not sure why
it fails. So question is if this is supposed to work or am I doing
something wrong or any clues what may be missing? I'm trying with this
command line with v3.1.0-rc3:

qemu-system-arm -M raspi2 -serial stdio \
-kernel rpi-kernel7.img -dtb bcm2709-rpi-2-b.dtb \
-append "rw earlyprintk loglevel=8 console=ttyAMA0,115200
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" \
-drive file=2018-10-09-raspbian-stretch-lite.img,format=raw,if=sd

Kernel starts to boot, I see raspberries on the guest screen and log
output to serial:

Booting Linux on physical CPU 0xf00
Linux version 4.14.71-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3
(crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1145 SMP Fri Sep 21
15:38:35 BST 2018
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[...]





My version (https://github.com/groeck/qemu) seems to work, using 
multi_v7_defconfig.
Logs from boots with qemu 3.0 and 3.1 attached.

Command line:

/opt/buildbot/qemu-install/v3.0/bin/qemu-system-arm \
-M raspi2 -kernel arch/arm/boot/zImage -no-reboot \
-snapshot -drive file=core-image-minimal-qemuarm.ext3,format=raw,if=sd \
--append 'earlycon=pl011,0x3f201000 root=/dev/mmcblk0 rootwait rw 
console=ttyAMA0 noreboot' \
-dtb arch/arm/boot/dts/bcm2836-rpi-2-b.dtb \
-nographic -monitor null -serial stdio

Guenter
SMC cmd 0x0 val 0x31
SMC cmd 0x0 val 0x31
SMC cmd 0x0 val 0x31
SMC cmd 0x0 val 0x31
[0.00] Booting Linux on physical CPU 0xf00
[0.00] Linux version 4.20.0-rc4-00149-gf92a2ebb3d55 (gro...@server.roeck-us.net) (gcc version 7.3.0 (GCC)) #1 SMP Thu Nov 29 17:18:19 PST 2018
[0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[0.00] OF: fdt: Machine model: Raspberry Pi 2 Model B
[0.00] earlycon: pl11 at MMIO 0x3f201000 (options '')
[0.00] printk: bootconsole [pl11] enabled
[0.00] Memory policy: Data cache writealloc
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 64 MiB at 0x3800
[0.00] random: get_random_bytes called from start_kernel+0xa0/0x468 with crng_init=0
[0.00] percpu: Embedded 17 pages/cpu @(ptrval) s40140 r8192 d21300 u69632
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 244224
[0.00] Kernel command line: earlycon=pl011,0x3f201000 root=/dev/mmcblk0 rootwait rw console=ttyAMA0 noreboot
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 887180K/983040K available (12288K kernel code, 1612K rwdata, 4732K rodata, 2048K init, 396K bss, 30324K reserved, 65536K cma-reserved, 131072K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0x(ptrval) - 0x(ptrval)   (13280 kB)
[0.00]   .init : 0x(ptrval) - 0x(ptrval)   (2048 kB)
[0.00]   .data : 0x(ptrval) - 0x(ptrval)   (1613 kB)
[0.00].bss : 0x(ptrval) - 0x(ptrval)   ( 397 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] rcu: Hierarchical RCU implementation.
[0.00] rcu: 	RCU event tracing is enabled.
[0.00] rcu: 	RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=4.
[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
[0.00] clocksource: timer: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns
[0.00] bcm2835: system timer (irq = 27)
[0.00] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
[0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
[0.29] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
[0.000494] Switching to timer-based delay loop, resolution 16ns
[0.004456] Console: colour dummy device 80x30
[0.005906] Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000)
[

Re: [Qemu-devel] Booting Raspbian on RPi emulation

[Philippe Mathieu-Daudé]

Hi Zoltan,

On 29/11/18 21:29, BALATON Zoltan wrote:
> Hello,
> 
> I could not boot Raspbian on QEMU's raspi emulation and I'm not sure why
> it fails. So question is if this is supposed to work or am I doing
> something wrong or any clues what may be missing? I'm trying with this
> command line with v3.1.0-rc3:
> 
> qemu-system-arm -M raspi2 -serial stdio \
> -kernel rpi-kernel7.img -dtb bcm2709-rpi-2-b.dtb \
> -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200
> dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" \
> -drive file=2018-10-09-raspbian-stretch-lite.img,format=raw,if=sd
> 
> Kernel starts to boot, I see raspberries on the guest screen and log
> output to serial:
> 
> Booting Linux on physical CPU 0xf00
> Linux version 4.14.71-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3
> (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1145 SMP Fri Sep 21
> 15:38:35 BST 2018
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> [...]
> 
> I get a lot of warnings like these:
> 
> bcm2835-clk 3f101000.cprman: plla: couldn't lock PLL
> 
> which I think are due to missing clock part emulation and I've also
> tried with the corresponding patch that got rid of these but apart from
> that failed similarly (see below).
> 
> The problem seems to be that the SD card with the root filesystem is not
> found. I get these mmc related logs:
> 
> sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
> mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
> 
> and then eventually ends with:
> 
> mmc0: host does not support reading read-only switch, assuming write-enable
> mmc0: Problem switching card into high-speed mode!
> mmc0: new SDHC card at address 4567
> VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0): error -6
> Please append a correct "root=" boot option; here are the available
> partitions:
> 0100    4096 ram0
>  (driver?)
> 0101    4096 ram1
>  (driver?)
> 0102    4096 ram2
>  (driver?)
> 0103    4096 ram3
>  (driver?)
> 0104    4096 ram4
>  (driver?)
> 0105    4096 ram5
>  (driver?)
> 0106    4096 ram6
>  (driver?)
> 0107    4096 ram7
>  (driver?)
> 0108    4096 ram8
>  (driver?)
> mmcblk0: mmc0:4567 QEMU! 1.74 GiB
> 0109    4096 ram9
>  (driver?)
> 010a    4096 ram10
>  (driver?)
> 010b    4096 ram11
>  (driver?)
> 010c    4096 ram12
>  (driver?)
> 010d    4096 ram13
>  (driver?)
> 010e    4096 ram14
>  (driver?)
> 010f    4096 ram15
>  (driver?)
> b300 1822720 mmcblk0
>  driver: mmcblk
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
> CPU: 3 PID: 1 Comm: swapper/0 Tainted: G    W   4.14.71-v7+ #1145
> Hardware name: BCM2835
> [<8010ffd4>] (unwind_backtrace) from [<8010c240>] (show_stack+0x20/0x24)
> [<8010c240>] (show_stack) from [<80787f24>] (dump_stack+0xd4/0x118)
> [<80787f24>] (dump_stack) from [<8011dcb4>] (panic+0xf0/0x274)
> [<8011dcb4>] (panic) from [<80b014f8>] (mount_block_root+0x1e8/0x2b8)
> [<80b014f8>] (mount_block_root) from [<80b017e8>] (mount_root+0x12c/0x134)
> [<80b017e8>] (mount_root) from [<80b01990>] (prepare_namespace+0x1a0/0x1e8)
> [<80b01990>] (prepare_namespace) from [<80b010ac>]
> (kernel_init_freeable+0x2a8/0x2bc)
> [<80b010ac>] (kernel_init_freeable) from [<8079cf80>]
> (kernel_init+0x18/0x128)
> [<8079cf80>] (kernel_init) from [<8010810c>] (ret_from_fork+0x14/0x28)
> CPU0: stopping
> CPU: 0 PID: 61 Comm: mmcqd/0 Tainted: G    W   4.14.71-v7+ #1145
> Hardware name: BCM2835
> [<8010ffd4>] (unwind_backtrace) from [<8010c240>] (show_stack+0x20/0x24)
> [<8010c240>] (show_stack) from [<80787f24>] (dump_stack+0xd4/0x118)
> [<80787f24>] (dump_stack) from [<8010e458>] (handle_IPI+0x2bc/0x33c)
> [<8010e458>] (handle_IPI) from [<801014d8>]
> (bcm2836_arm_irqchip_handle_irq+0x7c/0xac)
> [<801014d8>] (bcm2836_arm_irqchip_handle_irq) from [<807a3abc>]
> (__irq_svc+0x5c/0x7c)
> Exception stack(0xba283ca0 to 0xba283ce8)
> 3ca0: ba9fa1c0 ba9fa200 a013 ba9fa240 ba9fa1c0 ba158580 014000c0
> ba158588
> 3cc0: 000d0418 ba9f9548  ba283d3c ba283ca8 ba283cf0 80277598
> 80272874
> 3ce0: 4013 
> [<807a3abc>] (__irq_svc) from [<80272874>] (dma_pool_alloc+0x9c/0x23c)
> [<80272874>] (dma_pool_alloc) from [<804fb694>]
> (bcm2835_dma_create_cb_chain+0x1b4/0x214)
> [<804fb694>] (bcm2835_dma_create_cb_chain) from [<804fbb9c>]
> (bcm2835_dma_prep_slave_sg+0x12c/0x2a8)
> [<804fbb9c>] (bcm2835_dma_prep_slave_sg) from [<806385d8>]
> (bcm2835_sdhost_request+0x418/0x5fc)
> [<806385d8>] (bcm2835_sdhost_request) from [<806194bc>]
> (__mmc_start_request+0x78/0x1a8)
> [<806194bc>] (__mmc_start_request) from [<8061a030>]
> (mmc_start_request+0x158/0x184)
> [<8061a030>] (mmc_start_request) from [<8061a2d8>]
> (mmc_start_areq+0x27c/0x3d0)
> [<8061a2d8>] (mmc_start_areq) from [<8062b864>]
> (mmc_blk_issue_rw_rq+0xa8/0x3ac)
> [<8062b864>] (mmc_blk_issue_rw_rq) from [<8062c838>]
> 

[Qemu-devel] Booting Raspbian on RPi emulation

[BALATON Zoltan]

Hello,

I could not boot Raspbian on QEMU's raspi emulation and I'm not sure why 
it fails. So question is if this is supposed to work or am I doing 
something wrong or any clues what may be missing? I'm trying with this 
command line with v3.1.0-rc3:


qemu-system-arm -M raspi2 -serial stdio \
-kernel rpi-kernel7.img -dtb bcm2709-rpi-2-b.dtb \
-append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 
root=/dev/mmcblk0p2" \
-drive file=2018-10-09-raspbian-stretch-lite.img,format=raw,if=sd

Kernel starts to boot, I see raspberries on the guest screen and log 
output to serial:


Booting Linux on physical CPU 0xf00
Linux version 4.14.71-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG 
crosstool-ng-1.22.0-88-g8460611)) #1145 SMP Fri Sep 21 15:38:35 BST 2018
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[...]

I get a lot of warnings like these:

bcm2835-clk 3f101000.cprman: plla: couldn't lock PLL

which I think are due to missing clock part emulation and I've also tried 
with the corresponding patch that got rid of these but apart from that 
failed similarly (see below).


The problem seems to be that the SD card with the root filesystem is not 
found. I get these mmc related logs:


sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)

and then eventually ends with:

mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: Problem switching card into high-speed mode!
mmc0: new SDHC card at address 4567
VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
01004096 ram0
 (driver?)
01014096 ram1
 (driver?)
01024096 ram2
 (driver?)
01034096 ram3
 (driver?)
01044096 ram4
 (driver?)
01054096 ram5
 (driver?)
01064096 ram6
 (driver?)
01074096 ram7
 (driver?)
01084096 ram8
 (driver?)
mmcblk0: mmc0:4567 QEMU! 1.74 GiB
01094096 ram9
 (driver?)
010a4096 ram10
 (driver?)
010b4096 ram11
 (driver?)
010c4096 ram12
 (driver?)
010d4096 ram13
 (driver?)
010e4096 ram14
 (driver?)
010f4096 ram15
 (driver?)
b300 1822720 mmcblk0
 driver: mmcblk
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
CPU: 3 PID: 1 Comm: swapper/0 Tainted: GW   4.14.71-v7+ #1145
Hardware name: BCM2835
[<8010ffd4>] (unwind_backtrace) from [<8010c240>] (show_stack+0x20/0x24)
[<8010c240>] (show_stack) from [<80787f24>] (dump_stack+0xd4/0x118)
[<80787f24>] (dump_stack) from [<8011dcb4>] (panic+0xf0/0x274)
[<8011dcb4>] (panic) from [<80b014f8>] (mount_block_root+0x1e8/0x2b8)
[<80b014f8>] (mount_block_root) from [<80b017e8>] (mount_root+0x12c/0x134)
[<80b017e8>] (mount_root) from [<80b01990>] (prepare_namespace+0x1a0/0x1e8)
[<80b01990>] (prepare_namespace) from [<80b010ac>] 
(kernel_init_freeable+0x2a8/0x2bc)
[<80b010ac>] (kernel_init_freeable) from [<8079cf80>] (kernel_init+0x18/0x128)
[<8079cf80>] (kernel_init) from [<8010810c>] (ret_from_fork+0x14/0x28)
CPU0: stopping
CPU: 0 PID: 61 Comm: mmcqd/0 Tainted: GW   4.14.71-v7+ #1145
Hardware name: BCM2835
[<8010ffd4>] (unwind_backtrace) from [<8010c240>] (show_stack+0x20/0x24)
[<8010c240>] (show_stack) from [<80787f24>] (dump_stack+0xd4/0x118)
[<80787f24>] (dump_stack) from [<8010e458>] (handle_IPI+0x2bc/0x33c)
[<8010e458>] (handle_IPI) from [<801014d8>] 
(bcm2836_arm_irqchip_handle_irq+0x7c/0xac)
[<801014d8>] (bcm2836_arm_irqchip_handle_irq) from [<807a3abc>] 
(__irq_svc+0x5c/0x7c)
Exception stack(0xba283ca0 to 0xba283ce8)
3ca0: ba9fa1c0 ba9fa200 a013 ba9fa240 ba9fa1c0 ba158580 014000c0 ba158588
3cc0: 000d0418 ba9f9548  ba283d3c ba283ca8 ba283cf0 80277598 80272874
3ce0: 4013 
[<807a3abc>] (__irq_svc) from [<80272874>] (dma_pool_alloc+0x9c/0x23c)
[<80272874>] (dma_pool_alloc) from [<804fb694>] 
(bcm2835_dma_create_cb_chain+0x1b4/0x214)
[<804fb694>] (bcm2835_dma_create_cb_chain) from [<804fbb9c>] 
(bcm2835_dma_prep_slave_sg+0x12c/0x2a8)
[<804fbb9c>] (bcm2835_dma_prep_slave_sg) from [<806385d8>] 
(bcm2835_sdhost_request+0x418/0x5fc)
[<806385d8>] (bcm2835_sdhost_request) from [<806194bc>] 
(__mmc_start_request+0x78/0x1a8)
[<806194bc>] (__mmc_start_request) from [<8061a030>] 
(mmc_start_request+0x158/0x184)
[<8061a030>] (mmc_start_request) from [<8061a2d8>] (mmc_start_areq+0x27c/0x3d0)
[<8061a2d8>] (mmc_start_areq) from [<8062b864>] (mmc_blk_issue_rw_rq+0xa8/0x3ac)
[<8062b864>] (mmc_blk_issue_rw_rq) from [<8062c838>] 
(mmc_blk_issue_rq+0x2b4/0x74c)
[<8062c838>] (mmc_blk_issue_rq) from [<8062cd48>] (mmc_queue_thread+0x78/0x14c)
[<8062cd48>] (mmc_queue_thread) from [<8013dad4>] (kthread+0x13c/0x16c)
[<8013dad4>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28)
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1