Can ARM qemu system emulator boot from card image without kernel param?

Question

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?

Answer 1

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

Answer 2

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.