I am trying to use QEMU to load u-boot so I can interface with the console there. The ultimate target for u-boot does not have a serial port, so the easiest way I can interface with the u-boot console is via an emulator.
When I run the emulator with these flags, the emulator starts, but nothing is printed to the console:
qemu-system-ppc -nographic -M virtex-ml507 -cpu 440epx -kernel u-boot.bin -dtb virtex440-ml507.dtb -serial mon:stdio -append 'console=ttyS0'
This is a combination of the suggestions found here and here.
I have attempted running the program without the -nographic flag, but receive the error gtk initialization failed.
I have also tried running the emulator with more "standard" inputs:
qemu-system-ppc -nographic -M virtex-ml507 -cpu 440epx -kernel zImage -dtb virtex440-ml507.dtb -initrd ramdisk.image.gz -serial mon:stdio -append 'console=ttyS0'
You might note that I am using a zImage there instead of bzImage. Currently, when I build the kernel, there is no bzImage produced. In the interests of thoroughness, I have also subbed in vmlinux for zImage to no avail.
I have also tried running the emulator without the -serial and -append flags, allowing the emulator to handle I/O, as described in the first guide.
QEMU seems to run correctly i.e. not hang, since I can still enter the command mode as well as exit normally. It seems like this is an entry point issue, but I would figure entry points would be handled by the emulator, and I haven't seen any guides telling me to specify them. It may also be that the files I'm using are broken in some way, since I haven't ran them on anything else, but my builds complete seemingly correctly.
The first thing to bear in mind is that in general, U-Boot and QEMU and PowerPC only has been known to work for the 'qemu-ppce500' build target, and that is a different CPU family than the 440 that you're targetting above. All of that said, when trying to do what you're doing, for PowerPC you need to use the -bios flag and the argument is the u-boot file that is built. You do not need nor want to pass -dtb, -kernel, nor -append.
Related
I am self-studying the 2019 version of MIT 6.828/6.S081: Operating System Engineering.
I was trying to attach GDB to xv6 running on RISC-V using QEMU, to learn about what is going on when context switching happens between user mode and kernel mode.
After doing make qemu-gdb and gdb in the same directory, my GDB connected to QEMU successfully. However:
(gdb) x/2i $pc
=> 0xd8c: ecall
0xd90: ret
The problem is: Now if I stepi, it "jumps over" to 0xd90 instead of stepping into the kernel space.
Additionally, accessing any kernel addresses is not allowed, as if I was debugging a normal userland program:
(gdb) i r stvec
stvec 0x3ffffff000 274877902848
(gdb) x/i $stvec
0x3ffffff000: Cannot access memory at address 0x3ffffff000
Environment:
Host VM: Manjaro 19.0.2
sudo pacman -Syy
sudo pacman -S riscv64-linux-gnu-binutils riscv64-linux-gnu-gcc riscv64-linux-gnu-gdb qemu-arch-extra
GDB: 9.1
QEMU: 4.2.0
GCC: 9.2.0
Much appreciate anyone could share some insight about what is going on here. Thanks a lot!
I guess you run your code on ubuntu, that is the problem I experienced, then I change to mac, and flow mit tools tutorials, finally, it works.
run make CPUS=1 qemu-gdb in one window.
run riscv64-unknown-elf-gdb in another window.
ignore the Python Exception
I managed to get around this problem by building the riscv toolchain as explained here.
Building the toolchain as explained in the site, generates a generic ELF/Newlib toolchain identified with the prefix riscv64-unknown-elf- in contrast to the more sophisticated Linux-ELF/glibc toolchain identified by the prefix riscv64-unknown-linux-gnu-. The Newlib build allows the debugger to stepi into kernel space.
For crossdev users it is possible to build the toolchain with Newlib support by running:
crossdev --ex-gcc --ex-gdb --target riscv64-unknown-elf
Our hardware vendor provides us the yocto based rootfs for a gateway device (ARM softfloat) as a tar file. This file includes kernel image and the DTB files for that board. Is it possible to run this rootfs with no or minimal modifications using qemu? I extracted the tar file and created a CPIO archive (kept kernel image outside) and tried this command :
sudo qemu-system-arm -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -kernel boot/zImage -initrd ../initramfs.gz -machine versatilepb -m 2012
But it just showed blank UI window. Is this not possible?
Or do I need to ask our hardware vendor for a yocto build with MACHINE set as "qemuarm"?
Note: Its OK if QEMU is unable to simulate any hardware from the DTBs
It is highly unlikely that this will work to a sufficient extent. However, your hardware vendor is legally obliged to hand out the sources, and (given some jurisdictional nitpicking) also the the metadata layers used to build the rootfs. So instead of asking then for a favor, just ask for your rights and then build whatever you need to help your development/debugging needs.
NOTE: this might exclude sources to custom applications that they provide. If you intend to use such, it is up for discussion.
I'm learning how to write a basic OS kernel with intermezzos.github.io
I'm running in Windows Subsystem for Linux on Windows 10 v1607.
I'm at the point where I want to run my .iso with qemu-systems-x86_64 -cdrom os.iso.
Previously I was able to run the command and QEMU would run a window, which was running into another problem, posted here: QEMU, No bootable device, Windows Subsystem for Linux
Now when running the command, I receive the following error: Could not initialize SDL(No available video device) - exiting
When I ran into this problem before I installed Xming, ran it, and then QEMU successfully ran. But now, when I try to run Xming it no longer solves the problem.
I even tried installing xorg and running startx on WSL but that starts another issue: xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
I really don't know what I'm doing and I have so many questions.
I'm under the impression that for QEMU to successfully run, it needs to be able to find a video driver. Is that the purpose of X11?
I am able to get qemu-system-x86_64 -cdrom os.iso to run the expected window after setting: export DISPLAY=:0
Partially solves my problem because I'm still running into QEMU, No bootable device, Windows Subsystem for Linux
I'm wondering if I'm setting the DISPLAY environment variable correctly.
Here's documentation on the DISPLAY variable, for anyone else that wants to learn: http://gerardnico.com/wiki/linux/display
Anyway, this portion is solved!
I am trying to compile a kernel module of kernel version 3.2.0 on a linux kernel bzImage loaded on a qemu emulator, however I am getting the following error:
/lib/modules/3.2.0/build no such file or directory. I tried to look up solutions over the net but nothing specific related to solve this for a kernel image being loaded over qemu. The command I issue to load the bzImage on qemu is qemu/qemu-system-x86_64 -m 2G -kernel ../linuxkernel/arch/x86/boot/bzImage -hda ../../sid.ext2 -append "root=/dev/sda"
bzImage only contain kernel's image, it doesn't contain files needed for build modules.
You should:
Find kernel headers(with some files built), corresponded to you kernel, and install them to directory, to which /lib/modules/3.2.0/build points.
Or build kernel from the sources by hands. In that case reference /lib/modules/<kernel-version>/build will point to your compiled source files automatically.
I want to run some programs on the High Performance Computer (With 8-core processor) in my department. Now I use that machine with ssh using terminal. The machine has Red Hat linux installed on it. But my programs need to run on Solaris. I use Nexenta Solaris for x86.
Can qemu be used to run Nexenta Solaris on that machine through terminal. I need to convince the administrator that it can, otherwise he won't install qemu on that machine and therefore allow me to use Solaris through a virtual machine. Also note that I don't use GUI with the Nexenta Solaris, just command line. In my machine, I use VMware to run it.
You can compile qemu for youself and install it into your home directory. There will be no kernel-mode qemu accelerator, but the qemu will work and the speed will be rather high.
Qemu has two options for non-gui start: http://wiki.qemu.org/download/qemu-doc.html
2.3.4 Display options:
-nographic
Normally, QEMU uses SDL to display the VGA output. With this option, you can totally disable graphical output so that QEMU is a simple command line application. The emulated serial port is redirected on the console. Therefore, you can still use QEMU to debug a Linux kernel with a serial console.
-curses
Normally, QEMU uses SDL to display the VGA output. With this option, QEMU can display the VGA output when in text mode using a curses/ncurses interface. Nothing is displayed in graphical mode.
Also it can send graphic output to another machine via VNC protocol (-vnc option)
Linux: -append 'console=ttyS0'
That option was also needed for Linux kernel be besides -nographic mentioned by osgx as in a comment:
qemu-system-x86_64 -append 'console=ttyS0' \
-initrd rootfs.cpio.gz \
-kernel bzImage \
-nographic \
-serial mon:stdio \
Now you can do the following:
Ctrl + A X: exit qemu, see: https://superuser.com/questions/1087859/how-to-quit-the-qemu-monitor-when-not-using-a-gui
Ctrl + C: gets passed to the guest
-append 'console=ttyS0' makes QEMU pass the console=ttyS0 kernel command line option to Linux, which tells the kernel to use a serial port instead of the display. The serial port sends characters between host and guest, instead of pixels on a display, and then QEMU can display those characters on the terminal.
-serial mon:stdio is optional in this minimal command, but it is generally a good idea to have around. E.g., it improves behaviour if you also want to add a handy -monitor telnet later on:
How to run qemu with -nographic and -monitor but still be able to send Ctrl+C to the guest and quit with Ctrl+A X?
https://unix.stackexchange.com/questions/167165/how-to-pass-ctrl-c-to-the-guest-when-running-qemu-with-nographic
This can be easily tested with Buildroot qemu_x86_64_defconfig. I've created this is a highly self-contained and automated setup that allows you to try this out easily
Related but with less OS constraints:
redirect QEMU window output to terminal running qemu
Redirect Qemu console to a file or the host terminal?
Tested on Ubuntu 18.04, QEMU 2.11.1.
FreeBSD
Got it working there too: How to boot FreeBSD image under Qemu
I've struggled this for a while and finally figured out how to get it to work for me:
You need to have SGABIOS installed. Interestingly this BIOS is not included in the debian qemu package, so you need to install it (as the superuser):
apt install sgabios
Then when you run qemu use the -device option to tell the virtural machine to use the sga output
qemu-system-i386 -nographic -device sga discimage.bin
Voila! works perfectly over ssh with both the monitor and text output sent through stdio. You can access the qemu monitor with C-a c.
cheers, ben
os terminal will not working qemu. So you should use putty on windows pc or you should use linux machine terminal.