Guest has not initialized the display (yet).

[zengming00]

I tried on win10 x64 but there is no graphic display

> qemu-system-arm.exe --version
QEMU emulator version 3.0.92 (v3.1.0-rc2-11731-ge7dfdcb196-dirty)
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers

> qemu-system-arm  -M versatilepb -cpu arm1176 -m 256 \
 -drive file=2019-09-26-raspbian-buster.img,index=0,media=disk,format=raw \
-net nic -net user,hostfwd=tcp::5022-:22 \
-dtb ./versatile-pb.dtb -kernel ./kernel-qemu-4.19.50-buster \
 -append "root=/dev/sda2 panic=1" -no-reboot

[alst-ovh]

Use kernel-qemu-4.14.79-stretch to have a gui with the buster image.

[riban-bw]

Gosh! That wasted a lot of my day trying to get this to work before I found this issue report. Is this a temporary work-around until the issue is resolved in the buster kernel image?

[alst-ovh]

Seems to be fixed, now it works with buster kernel ;-)

[riban-bw]

Not for me. I downloaded the Buster kernel today and get the same result, i.e. no output in qemu GUI window. Using the stretch image gives output as expected.

[alst-ovh]

If you wait a long time output should come. I think the problem ist that DRM in Kernel is or was enabled. I need Fuse so i recompile the Kernel and Modules without DRM and with FUSE as Module and it works for me. Copy the Modules do your qemu machine. You can Test it https://github.com/alst-ovh/qemu-rpi-kernel

[bmatthewshea]

Thank you for your hard work on these kernels. But same problem. I'm using headless Raspian (2020-02-13-raspbian-buster-lite.img) with buster kernel. Boots fine, but outputs to CMD / PS window only (where you started it).

The emulation window is never used as primary text console. I was under the impression it should used as console & graphics output? (I'm new to QEMU.)

Editing files is difficult since this is the case. Have to boot full environment (no init=bash) to even edit with nano or vi, and screen still isn't even close to right. Color escape codes, etc and other problems. (which is to be expected since windows)

One plus is the copy/paste works to some extent under cmd/ps. Though, it cuts off long lines.

Edit - Finally got PuTTY working with SSH so makes my edit problem a bit irrelevant now. But, still wondering if it should be using the emulation window for main console? Is this normal behavior?

[ProfDavidMora]

I second the thanks for the work done on making this kernels publicly available and for how good they work on most scenarios I've used them.

I've been trying to configure a Buster-based VM with QEMU for a couple days. I have fully working Jessie-based and Stretch-based machines with full GUI and text support (though I always turn off the desktop and use mostly SSH/SCP to work on them). Using the "serial stdio" parameter, that I haven't used before today, I was able to configure and use the network protocols in the Buster machine. That was not necessary in the previous versions since I could do it all in the local console, which is more straightforward or at least more "expected" from an user-perspective.

The Buster machine doesn't initialize the display while the Stretch machine does. Both of them show the "vpb_sic_write: Bad register offset 0x2c" message, but since it appears on both, I don't suspect it being relevant for the display initialization. They look as the following screenshot:

This is the output of both machines including the commands used to start them all the way to the login prompt if they are useful: 02 QEMU-Output.txt

I would love to see the Buster kernel working on this part, so, any further ideas that can be attempted? Any plans to update the buster kernel? Any information/work I can provide to get this addressed properly? With a little guidance I will be more than glad to do what I can to improve the kernel on this point, specially during this quarantine time :)

[puhitaku]

I've fixed this issue and posted a PR #104 . Here's the detail for those who are interested in...

Every graphic problems should be reported in Xorg log so let's see it:

pi@raspberrypi:~$ cat /var/log/Xorg.0.log
...
[    61.474] (EE) no screens found(EE)
...

X says that there's no framebuffer and it can't continue its job. The next thing to see is dmesg.

pi@raspberrypi:~$ dmesg | grep pl111
[    0.315590] drm-clcd-pl111 dev:20: No bridge, exiting

Why the graphic driver (pl111) exits? A hint is in a patch which was merged into mainline since 4.17, between 4.14 (Stretch) and 4.19 (Buster).

It does a more strict check than before and exits as a result.

The "bridge" means a component of DRM/KMS pipeline. In fact, the document says we have to declare nodes more than the original device tree. DRM/KMS can finally know what kind of display is connected with the pipeline I constructed.

$ dtc -I dtb -O dts versatile-pb.dtb > before 2> /dev/null
$ dtc -I dtb -O dts versatile-pb-buster.dtb > after 2> /dev/null
$ diff before after
--- before      2020-04-23 22:50:13.098735974 +0900
+++ after       2020-04-23 22:50:22.673587318 +0900
@@ -31,6 +31,45 @@
                phandle = < 0x02 >;
        };

+       bridge {
+               compatible = "dumb-vga-dac";
+
+               ports {
+                       #address-cells = < 0x01 >;
+                       #size-cells = < 0x00 >;
+
+                       port@0 {
+                               reg = < 0x00 >;
+
+                               endpoint {
+                                       remote-endpoint = < 0x07 >;
+                                       phandle = < 0x0a >;
+                               };
+                       };
+
+                       port@1 {
+                               reg = < 0x01 >;
+
+                               endpoint {
+                                       remote-endpoint = < 0x08 >;
+                                       phandle = < 0x09 >;
+                               };
+                       };
+               };
+       };
+
+       vga {
+               compatible = "vga-connector";
+
+               port {
+
+                       endpoint {
+                               remote-endpoint = < 0x09 >;
+                               phandle = < 0x08 >;
+                       };
+               };
+       };
+
        core-module@10000000 {
                compatible = "arm,core-module-versatile\0syscon\0simple-mfd";
                reg = < 0x10000000 0x200 >;
@@ -241,7 +280,16 @@
                        reg = < 0x10120000 0x1000 >;
                        interrupts = < 0x10 >;
                        clocks = < 0x04 0x03 >;
-                       clock-names = "clcd\0apb_pclk";
+                       clock-names = "clcdclk\0apb_pclk";
+
+                       port {
+
+                               endpoint {
+                                       remote-endpoint = < 0x0a >;
+                                       arm,pl11x,tft-r0g0b0-pads = < 0x00 0x08 0x10 >;
+                                       phandle = < 0x07 >;
+                               };
+                       };
                };

                sctl@101e0000 {

Of course, the display is virtualized; the dumb-vga-dac is suitable for our use case. Generally, it reads an EDID from displays but it falls back to XGA (1024x768) when it cannot. The resolution xrandr reported (1024x768) came from that.

[puhitaku]

Time to close here? Thanks merging! @dhruvvyas90

[ProfDavidMora]

Very informative resolution, thank you so much @puhitaku!