earlycon would probably be sufficient debug output to identify this issue. PS: my first guess is that the kernel is crashing because it doesn't have enough memory - you haven't passed QEMU a '-m' option, so it is defaulting to 128MB the vexpress-a9 board can handle up to 1GB. Nothing about this is particularly QEMU specific - it's the same sort of pain you have to go through if you're trying to do kernel bringup on hardware. To start a new virtual machine using the qemu-system utility, perform the following steps: Start a new QEMU virtual machine using the x8664 CPU architecture: rootkvm: qemu-system-x8664 -name debian -vnc 146.20.141.254:0 -cpu Nehalem -m 1024 -drive formatraw,index2,filedebian. if all else fails, you have to break out the debugger to find out what's going on.if you have a kernel that works, and one that doesn't, look at the differences between the kernel configs to see if one is missing something.
#Qemu system arm command no output windows serial#
give yourself the maximum chance of being able to see something, by configuring QEMU to output serial port information, and configuring the guest to send its console output to serial, and enabling any earlycon/earlyprintk options you can (serial output happens much earlier than graphics output, and the Linux kernel earlycon/earlyprintk options mean the kernel will start printing output earlier than it defaults to).check the obvious kernel config options are set correctly: in particular, that you have built it to support the ARM board and CPU that you're trying to run it on, and that you've enabled support for whatever devices you're trying to use for console output.This is pretty much the same effect you get if you try to boot a wrongly configured kernel on real hardware, and the process for debugging it is about the same: "QEMU sits there and prints nothing" is quite a common symptom, and it almost always means "the guest kernel crashed before being able to print anything, because it wasn't configured correctly".
0 kommentar(er)
