I compiled the Linux Kernel and run it successfully on Qemu, but I want to run a non-linux operating system.
I have a file named RTOS.elf, compiled for PowerPC. I'm trying this code, but I can't get any results.
qemu-system-ppc -M ppce500 -m 512 -kernel RTOS.elf -nographic
Related
I want to test some use-cases which need to run on 'ppc64le' architecture but I don't have a host machine with ppc64le architecture.
My host system is of x86_64 architecture. Is it possible to run VM with 'ppc64le' architecture on my host machine with x86_64 architecture?
Absolutely! The only caveat is that since you're not running natively, the virtual machine needs to emulate the target (ppc64le) instruction set. This can be much slower than running native instructions.
The way to do this will depend on which tools you're using to manage your virtual machine instances. For example, virt-manager allows you to select the architecture type when you're creating a new virtual machine. If you set this to ppc64el, you'll get a ppc64el machine. Other options (like disk and network devices) can be set just like native VMs.
If you're not using any specific VM management tools, the following invocation of qemu will get a ppc64el machine going easily:
qemu-system-ppc64le \
-M pseries # use the pseries machine model \
-m 4G # with 4G of RAM \
-hda ubuntu-18.04-server-ppc64el.iso # Ubuntu installer as a virtual disk
Depending on your usage, you may want to use the following options too:
-nographic -serial pty to use a text console instead of an emulated graphics device. qemu will print the console pty on startup - something like /dev/pts/X. Run screen /dev/pts/X to access it.
-M powernv -bios skiboot.lid to use the non-virtualised ppc64el machine model, which is closer to current OpenPOWER hardware. The skiboot.lid firmware may be included in your distro's install of qemu.
-drive, -device and -netdev to configure virtual disks and networking. These work in the same manner at x86 VMs on qemu.
I hosted centos7-ppc64le on my x86_64 machine(OS RHEL-7). I used qemu + virt-install for that. First install qemu as
wget https://download.qemu.org/qemu-3.1.0-rc1.tar.xz
tar xvJf qemu-3.1.0-rc1.tar.xz
cd qemu-3.1.0-rc1
./configure
make
make install
After installation check qemu-system-ppc64le is available from the command line. Then install virt-manager,virt-install,virt-viewer and libvirt for managing the VM's. Then I started the VM as
virt-install --name centos7-ppc64le \
--disk centos7-ppc64le.qcow2 \
--machine pseries \
--arch ppc64 \
--vcpus 2 \
--cdrom CentOS-7-ppc64le-Minimal-1804.iso \
--memory 2048 \
--network=bridge:virbr0 \
--graphics vnc
Good day,
So I am following this coreboot v3 + OpenBIOS tutorial Here .
In the instructions I have the following...
mkdir foo
cd foo
wget http://www.coreboot.org/images/9/9d/Qemu_coreboot_openbios.zip
wget http://www.coreboot.org/images/0/0d/Vgabios-cirrus.zip
unzip Qemu_coreboot_openbios.zip
unzip Vgabios-cirrus.zip
mv qemu_coreboot_openbios.bin bios.bin
cd ..
qemu -L foo -hda /dev/zero -serial stdio
I noticed that qemu has been replace or is implemented with qemu-system.
command I am running
qemu-x86_64 -L foo -hda /dev/zero -serial stdio
When I run the command, I see just qemu run it's typical and not find a disk.(which I expect since the disk switch points to /dev/zero) but none of the payloads run as I would expect from the tutorial.
What am I doing incorrectly?
Should I use a different version of qemu?
Should I create a dummy disk for this?
Qemu seems to be ignoring the files in the foo directory.
The examples are not up to date, as you have noticed by the renaming of qemu to qemu-system-x86_64.
I managed to get the examples to work using only the cirrus video card, and by renaming the outputs of the zips (bin - bios files to bios-256k.bin). I did this because by adding the -L option I specify the bios location and qemu will look for a file called bios-256k.bin as the bios. The command to run the bios with cirrus (all done while in the foo directory) was
qemu-system-x86_64 -L . -vga cirrus -serial stdio
Both machine types pc and q35 worked.
I've seen a lot of examples how to run a QEMU ARM board emulator. In every case, besides SD card image param, QEMU was also always supplied with kernel param, i.e.:
qemu-system-arm -M versatilepb \
-kernel vmlinuz-2.6.18-6-versatile \ #KERNEL PARAM HERE
-initrd initrd.gz \
-hda hda.img -append "root=/dev/ram"
I am palying with bootloaders and want to create my own bootable SD card, but don't have a real board yet and want to learn with an emulated one. However, if run as described above, QEMU skips bootloader stage and runs kernel.
So what should I do to emulate a full boot sequence on QEMU so that it executes bootloader? Should I get a ROM dump and pass it as a -bios param?
You can do that by feeding the uboot image. I never used ROM dump.
QEMU BOOT SEQUENCE:
On real, physical boards the boot process usually involves a non-volatile memory (e.g. a Flash) containing a boot-loader and the operating system. On power on, the core loads and runs the boot-loader, that in turn loads and runs the operating system.
QEMU has the possibility to emulate Flash memory on many platforms, but not on the VersatilePB. There are patches ad procedures available that can add flash support, but for now I wanted to leave QEMU as it is.
QEMU can load a Linux kernel using the -kernel and -initrd options; at a low level, these options have the effect of loading two binary files into the emulated memory: the kernel binary at address 0x10000 (64KiB) and the ramdisk binary at address 0x800000 (8MiB).
Then QEMU prepares the kernel arguments and jumps at 0x10000 (64KiB) to execute Linux. I wanted to recreate this same situation using U-Boot, and to keep the situation similar to a real one I wanted to create a single binary image containing the whole system, just like having a Flash on board. The -kernel option in QEMU will be used to load the Flash binary into the emulated memory, and this means the starting address of the binary image will be 0x10000 (64KiB).
This example is based of ARM versatilepb board
make CROSS_COMPILE=arm-none-eabi- versatilepb_config
make CROSS_COMPILE=arm-none-eabi- all
Creating the Flash image
* download u-boot-xxx.x source tree and extract it
* cd into the source tree directory and build it
mkimage -A arm -C none -O linux -T kernel -d zImage -a 0x00010000 -e 0x00010000 zImage.uimg
mkimage -A arm -C none -O linux -T ramdisk -d rootfs.img.gz -a 0x00800000 -e 0x00800000 rootfs.uimg
dd if=/dev/zero of=flash.bin bs=1 count=6M
dd if=u-boot.bin of=flash.bin conv=notrunc bs=1
dd if=zImage.uimg of=flash.bin conv=notrunc bs=1 seek=2M
dd if=rootfs.uimg of=flash.bin conv=notrunc bs=1 seek=4M
Booting Linux
To boot Linux we can finally call:
qemu-system-arm -M versatilepb -m 128M -kernel flash.bin -serial stdio
You will need to pass it some kind of bootloader image via -bios (or a pflash option), yes. I doubt that a ROM dump would work though -- typically the ROM will assume much closer fidelity to the real hardware than QEMU provides. You'd want a bootloader written and tested to work with QEMU. One example of that is if you use the 'virt' board and a UEFI image which is built for QEMU.
Otherwise QEMU will use its "built in bootloader" which is a handful of instructions that are capable of booting the kernel you pass it with -kernel.
I've used buildroot to build a qemu compatible Linux kernel and root filesystem. I am emulating for the MPC8544DS machine and used the qemu_ppc_mpc8544ds_defconfig to generate these components. I was able to successfully build the kernel and the root filesystem. And was able to run it under qemu.
However when I tried to run uboot instead of the Linux Kernel (and the associated rootfs) it fails. Here is the way I invoke qemu to boot u-boot:
qemu-system-ppc -nographic -M mpc8544ds -m 512 -kernel ~/CrossCompilation/u-boot.bin and it fails like so:
Wrong image type 52, expected 2
qemu: could not load kernel '~/CrossCompilation/u-boot.bin'
I do not understand what else could be wrong. I've checked various blog posts over the internet and almost all of them use uboot.bin as the kernel (as opposed to srec and other formats)
could someone shed some light on the various image type numbers and which ones fit where?
UPDATE: This is how I compiled my u-boot
cd to u-boot dir
make distclean
make mrproper
make ARCH=powerpc CROSS_COMPILE=~/CrossCompilation/buildroot-2014.08/output/host/usr/bin/powerpc-buildroot-linux-gnuspe- MPC8544DS_defconfig
make ARCH=powerpc CROSS_COMPILE=~/CrossCompilation/buildroot-2014.08/output/host/usr/bin/powerpc-buildroot-linux-gnuspe-
Try removing the -kernel option. Make sure everything stay as is:
qemu-system-ppc -nographic -M mpc8544ds -m 512 ~/CrossCompilation/u-boot.bin
I compiled the Linux kernel (version 2.6.32) using the Emdebian ARM toolchain. Downloaded the initrd from Aurel's personal FTP server hosted on Debian here.
The ran qemu like so:
qemu-system-arm -M versatilepb -kernel zImage -hda hda.img -initrd initrd_versatile.gz -append "root=/dev/ram" -m 1024
Yet it fails with qemu reporting:
mount: mouting none of /run failed invalid argument.
Keen to hear if someone has something to say about this. As I search for it, could someone also let me know if it is possible to use an off the shelf initrd or is it related to the kernel version being run?
I was able to run the machine by cross compiling busybox, creating a cpio archive image and then using it like so:
qemu-system-arm -M versatilepb -m 128M -kernel zImage -initrd rootfs.img -append "root=/dev/ram rdinit=/bin/sh console=tty1"
Now that Ive got it working Ill investigate what those arguments actually mean.