CODEWITHSUNDEEP
qemuu-boot
JustWe
JustWe

Reputation: 4484

How to run u-boot on QEMU(raspi2)?

I am trying to run the u-boot on QEMU. But when start QEMU it gives nothing, so why this doesn't work and how to debug to find out the reason?

This is I tried:

  1. Install Ubuntu 18.04 WSL2 on Windows.

  2. Compile u-boot for the Raspi2

    sudo apt install make gcc bison flex
sudo apt-get install gcc-arm-none-eabi binutils-arm-none-eabi
export CROSS_COMPILE=arm-none-eabi-
export ARCH=arm
make rpi_2_defconfig all

  3. Start QEMU

    qemu-system-arm -M raspi2 -nographic -kernel ./u-boot/u-boot.bin

    And also tried QEMU on the Windows side, and the result is the same.

    PS C:\WINDOWS\system32> qemu-system-arm.exe -M raspi2 --nographic -kernel E:\u-boot\u-boot.bin

Then QEMU didn't give output, even I tried to ctrl+c cannot stop the process. enter image description here

Upvotes: 2

Views: 5423

Answers (1)

Peter Maydell
Peter Maydell

Reputation: 11383

Unfortunately this is an incompatibility between the way that u-boot expects to be started on the raspberry pi and the ways of starting binaries that QEMU supports for this board.

QEMU supports two ways of starting guest code on Arm in general:

  1. Linux kernels; these boot with whatever the expected boot protocol for the kernel on this board is. For raspi that will be "start the primary CPU, but put the secondaries in the pen waiting on the mbox". Effectively, QEMU emulates a very minimal bit of the firmware, just enough to boot Linux.

  2. Not Linux kernels; these are booted as if they were the first thing to execute on the raw hardware, which is to say that all CPUs start executing at once, and it is the job of the guest code to provide whatever penning of secondary CPUs it wants to do. That is, your guest code has to do the work of the firmware here, because it effectively is the firmware.

We assume that you're a Linux kernel if you're a raw image, or a suitable uImage. If you're an ELF image we assume you're not a Linux kernel. (This is not exactly ideal but we're to some extent lumbered with it for backwards-compatibility reasons.)

On the raspberry pi boards, the way the u-boot binary expects to be started is likely to be "as if the firmware launched it", which is not exactly the same as either of the two options QEMU supports. This mismatch tends to result in u-boot crashing (usually because it is not expecting the "all CPUs run at once" behaviour).

A fix would require either changes to u-boot so it can handle being launched the way QEMU launches it, or changes to QEMU to support more emulation of the firmware of this board (which QEMU upstream would be reluctant to accept).

An alternative approach if it's not necessary to use the raspi board in particular would be to use some other board like the 'virt' board which u-boot does handle in a way that allows it to boot on QEMU. (The 'virt' board also has better device support; for instance it can do networking and USB devices, which 'raspi' and 'raspi2' cannot at the moment.)

Upvotes: 5

Related Questions