blob: 10b22cc7aea6394eaf918152daa282734b6f01e1 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
debug: 0.806
mistranslation: 0.729
graphic: 0.705
virtual: 0.666
device: 0.644
semantic: 0.616
x86: 0.615
performance: 0.570
VMM: 0.526
user-level: 0.525
architecture: 0.430
network: 0.430
kernel: 0.428
register: 0.410
socket: 0.406
vnc: 0.395
permissions: 0.371
PID: 0.343
boot: 0.326
ppc: 0.324
hypervisor: 0.323
i386: 0.309
files: 0.307
peripherals: 0.285
risc-v: 0.266
TCG: 0.262
arm: 0.200
KVM: 0.174
assembly: 0.135
Running an edk2 based bios
This is not necessarily a bug, however I wasn't sure were to get help.
I am currently working on using QEMU to run a BIOS my company has developed. In order to see if the software was working correctly, I was able to successfully run the edk2 bios using the following command:
qemu-system-x86_64.exe -bios "C:\Users\matthew.intriago\Desktop\ovmf.fd" -net none
However, when running the same command using our personalized bios, QEMU launches stating that “guest has not initialized display”. Theoretically, QEMU should be able to run the bios since it is edk2 based, the only difference between the two is that our bios has more features.
If anyone has any insight on what the issue might be I would greatly appreciate any help.
"Guest has not initialized display" simply means that the guest code you're running has not done anything to the display device (VGA in this case). There are two main reasons for this:
(1) the guest code isn't intended to output to the display -- perhaps it sends its output to the serial port instead. In this case the fix is to use the right QEMU arguments to send the serial port output somewhere you can read it (or to reconfigure the guest code to output where you want it to).
(2) the guest code is intended to output to the display, but it crashed before it got as far as doing that. In this case, the fix is to debug your guest code. QEMU's gdbstub is usually a good tool to use here. If you control the guest code (ie you can modify and recompile it) you can also add extra debugging to it (like making it output more information earlier, or output debugging trace information to the serial port so you can see how far it has got).
My guess would be that this is a variation on 2 caused by your BIOS being compiled to assume different hardware from what QEMU is providing -- if the BIOS tries to write to a device that isn't present it will likely crash or go into an infinite loop.
|