After using SeaBIOS for a while, I realized that it's too old. I want to use ACPI 2.0+ for finding and using HPET instead of PIT and APIC timer. I have searched on Google and I know that I can add additional ACPI table to QEMU, but the problem here is I can't find any source for downloading ACPI. Can anyone suggest me?
qemu-system-x86_64 -M hpet=on should do the trick.
HPET emulation is off by default because of the virtualization overhead. qemu generates acpi tables matching the emulated hardware, so when the HPET is enabled it will also show up in the ACPI tables.
Related
I have been developing the OS for a prototype device using hardware. Unfortunately, it's a very manual and buggy process to flash the OS each time and then debug the issues.
I'd like to switch to developing the OS in QEMU, so that I can be sure that the OS is loading correctly before going through the faff of programming the device for real. This will come in handy later for Continuous Integration work.
I have a full copy of the NVM device that is generated from my build process. This is a known working image I'd like to run in QEMU as a start point. This is ready to then be JTAG'd onto the device. The partition layout is:
P0 - loader - Flash of IDBLoader from rockchip loader binaries
P1 - Uboot - Flash of Uboot
P2 - trust - Flash of Trust image for rockchip specific loader
P3 - / - Root partition with Debian based image and packages required for application
P4 - data partition - Application Data
I have not changed anything with the Rockchip partitions (P0 - P2) apart from the serial console settings. When trying to boot the image though, nothing happens. There is no output at all, but the VM shows as still running. I use the following command to run it:
qemu-system-aarch64 -machine virt -cpu cortex-a53 \
-kernel u-boot-nodtb.bin \
-drive format=raw,file=image.img \
-boot c -serial stdio
I have no error information to go on to understand what is going on with it, where can I get more information or debug?
QEMU cannot not emulate arbitrary hardware. You will have to compile U-Boot to match the hardware that QEMU emulates, e.g. using make qemu_arm64_defconfig. The OS must also provide drivers for QEMU's emulated hardware.
If you want to emulate the complete hardware to debug drivers, Renode (https://renode.io/) is a good choice.
For anyone else trying to figure this out, I found good resources here:
https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/
and
https://azeria-labs.com/emulate-raspberry-pi-with-qemu/
Looking at the information though, you need to extract the kernel from your image and provide that to the qemu command line as an argument. You'll also need to append an argument telling the system which partition to use as a root drive.
My final command line for starting the machine looks like this:
qemu-system-aarch64 -machine virt -cpu cortex-a53 \
-drive format=raw,file=image.img,id=hd \
-boot c -serial stdio
-kernel <kernelextracted> -append "root=fe04"
Different Arm boards can be significantly different from one another in where they put their hardware, including where they put basic hardware required for bootup (UART, RAM, interrupt controller, etc). It is therefore pretty much expected that if you take a piece of low-level software like u-boot or a Linux kernel that was compiled to run on one board and try to run it on a different one that it will fail to boot. Generally it won't be able to output anything because it won't even have been able to find the UART. (Linux kernels can be compiled to be generic and include drivers for a wider variety of hardware, so if you have that sort of kernel it can be booted on a different board type: it will use a device tree blob, provided either by you or autogenerated by QEMU for the 'virt' board, to figure out what hardware it's running on and adapt to it. But kernels compiled for a specific embedded target are often built with only the device drivers they need, and that kind of kernel can't boot on a different system.)
There are broadly speaking two paths you can take:
(1) build the guest for the board you're emulating (here the 'virt' one). u-boot and Linux both have support for QEMU's 'virt' board. This may or may not be useful for what you're trying to do -- you would be able to test any userspace level code that doesn't care what hardware it runs on, but obviously not anything that's specific to the real hardware you're targeting.
(2) In theory you could add emulation support to QEMU for the hardware you're trying to run on. However this is generally a fair amount of work and isn't trivial if you're not already familiar with QEMU internals. I usually ballpark estimate it as "about as much work as it would take to port the kernel to the hardware"; though it depends a bit on how much functionality you/your guest need to have working, and whether QEMU already has a model of the SoC your hardware is using.
To answer the general "what's the best way to debug a guest image that doesn't boot", the best thing is usually to connect an arm-aware gdb to QEMU's gdbstub. This gives you debug access broadly similar to a JTAG debug connection to real hardware and is probably sufficient to let you find out where the guest is crashing. QEMU also has some debug logging options under the '-d' option, although the logging is partially intended to assist in debugging problems within QEMU itself and can be a bit tricky to interpret.
What should be the best approach to run a C code in Qemu riscv and observe the output? I installed Qemu riscv following this link.What should I do now?
https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html
You probably want to use the static user mode version of Qemu for most applications.
Then make sure to compile for RISC-V with the -static flag, and call qemu-riscv64-static [executable].
I highly recommend this, the system mode is a massive pain to handle if you don't need it
(have fun debugging the UART).
You can use libriscv to run RISC-V programs: https://github.com/fwsGonzo/libriscv
Inside the emulator folder there are 2 ways to build the emulator. build.sh produces emulators that run programs with no instruction listing. debug.sh produces debugging variant that shows the state of registers and instructions all the way through the program.
Building Qemu from sources is complete overkill.
My laptop support hardware virtualization & enabled in bios & i am trying to compile qemu from source. So Is it possible to compile qemu in a way that i do not enter "-enable-kvm" flage from command line every time?
You could try passing configure --disable-tcg, which will disable the CPU emulation entirely (this only works for some target architectures like x86 at the moment). Then I think QEMU will default to KVM as the only available accelerator.
Alternatively if you rename your executable to something whose name ends with "kvm" then QEMU will default to the KVM accelerator rather than TCG. (I think a hardlink or maybe even a symlink to the binary will also work as well as simply renaming it, but haven't tested this.)
I'm learning how to build a basic OS kernel with https://intermezzos.github.io
I've create my .iso file and I'm at the point where I am runnning qemu-system-x86_64 -cdrom os.iso
When I press enter, QEMU runs a window with the following output:
Booting from Floppy...
Boot failed: could not read the boot disk
Booting from DVD/CD...
Boot failed: Could not read from CDROM (code 0004)
Booting from ROM...
iPXE (PCI 00:03.0) starting execution...ok
iPXE initializing devices...ok
iPXE 1.0.0+git-20131111.c3d1e78-2ubuntu1.1 -- Open Source Network Boot Firmware
-- http://ipxe.org
Features: HTTP HTTPS iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE Menu
net0: 52:54:00:12:34:56 using 82549em on PCI00:03.0 (open)
[Link:up, TX:0 TXE:0 RX:0 RXE:01]
Configuring (net0 52:54:00:12:34:56)...ok
net0: 10.0.2.15/255.255.255.0 gw 10.0.2.2
Nothing to boot: No such file for directory (http://ipxe.org/2d03e13b)
No more network devices
No bootable device.
I went to the website listed in the output (http://ipxe.org/2d03e13b) and one of the tips is that I might Use the iPXE command line to perform DHCP manually, however when I press CTRL + B to access cli, I'm not able to do so.
Where do I look next to troubleshoot this problem of not being able to boot my .iso?
How do I make QEMU have access to keyboard input?
UPDATE
I don't know how, but I'm am now able to use CTRL + B to access iPXE command line.
This seems like a good place to start diagnosing my problem of not being able to boot my .iso.
What am I looking for?
UPDATE 2
Thanks to Peter Maydell's suggestion below, I've tested a known-good iso image (https://alpinelinux.org/), running qemu-system-x86_64 -cdrom alpine-3.4.3-x86_64.iso and it booted perfectly just as I expected.
I've rewritten my files from https://intermezzos.github.io to create a new iso image, this time copy and pasting the code from the repository, just in case I was previously inputting typos.
Still not booting. On to the next clue...
The first thing to do is to check whether this command line and ISO image work on a normal Linux host system. That will tell you whether the problem is (a) the Windows Subsystem for Linux not correctly implementing something QEMU relies on or (b) your ISO image actually not being a bootable CDROM.
You might also try booting a known-good ISO image such as one for a Linux distribution.
(The general principle here is to try to do diagnostic tests to split the space of "what might be the problem" into smaller sections and determine which side your problem is.)
Simple solution to the problem. Has to do with systems that use EFI to boot.
source
I needed to apt-get install grub-pc-bin and then rebuild image.
I have PHPStorm, but when I'm writing native function (for example str_poss, return, parent...) it very often freeze for about 10 seconds. I have no idea what I'm doing wrong. But it happen to me on Windows7 and on Ubuntu also. Has anyone same trouble? Thanks.
PHPStorm used to "lag" for me before quite often too... but I managed to fix it in the following ways (It did take a bit of tweaking/experimenting though to get it to work! But now it is blazing fast once again!)
Here is what I did to optimize it:
1) If you are on Linux - Make sure you are using Oracle Java on your system, not Open JDK
From: https://intellij-support.jetbrains.com/entries/23455956-Selecting-the-JDK-version-the-IDE-will-run-under it says:
On windows: "JDK is bundled with all the product installers and it's recommended that you will use the provided JDK version unless there are any specific issues.
32-bit JDK is located in IDE_HOME\jre directory and is used by the 32-bit product executable.
To run the IDE in 64-bit mode you will need to download and install 64-bit JDK (not JRE) distribution and install it yourself. IDE will find and use it from the registry when you run the 64-bit .exe file (available only for IntelliJ IDEA right now, other products can use the .bat file to run in 64-bit mode)."
2) Disable any plugins you do not ABSOLUTELY NEED! Especially any 3rd party plugins you may have installed**
GBC from PhpStorm 7 very slow and sluggish on netbook, optimize IDE for responsiveness? also had some insties:
3) Disable language injections: File -> Settings -> Language injections. un-check as many boxes as you're comfortable with. HTML was the real killer for me.
4) Disable inspections: File -> Settings -> Inspections. uncheck as many as you don't need.
I hope this helps!
I am on a mounted VM drive and everytime I was going back to PHPStorm it freezes for 5-10 sec.
Unchecked the box "Synchronize files on frame activation", in Settings > General > Synchronization, seems to solve the issue for me.
PHPStorm 7.1 on Linux
A solution I found which drastically increased my speed without having to disable any plugins or disable inspections (because they are useful - why would you want to disable them) was to enable OpenGL.
First of all go to: path-to-phpstorm\bin\PhpStorm64.exe.vmoptions
Then add these two lines below the others:
-Dawt.useSystemAAFontSettings=lcd
-Dawt.java2d.opengl=true
This helped me to get that 'eye' logo disappear and show a green tick on 6000 line file in 3 seconds rather than 2 minutes. Amazing how much difference it made.
If you're using JetBrains Toolbox, go into the Settings beside PhpStorm and crank up the "Maximum heap size". I find about 3000 MB is good.
If you're not using Toolbox, find and open phpstorm64.vmoptions and add this line:
-Xmx3000m
It does the same thing.
I had the same problem on Ubuntu. The IDE was freezing regularly on two different PCs (Using a desktop pc at home and a laptop at work), both have as OS Ubuntu 18. The freezing time was about 1-2 minutes.
It stopped after I restart IDE with VM-option: -Dawt.ime.disabled=true
Source: https://youtrack.jetbrains.com/issue/JBR-1923