如何在QEMU（raspi2）上运行u-boot？

Question

我正在尝试在QEMU上运行u-boot。但是，当启动QEMU时，它什么也没有提供，所以为什么这不起作用以及如何调试以找出原因？

这是我尝试过的：

1. 在Windows上安装Ubuntu 18.04 WSL2。

2. 为Raspi2编译u-boot

   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. 开始QEMU

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

   并且还在Windows端尝试了QEMU，结果是相同的。

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

然后，QEMU没有给出输出，即使我试图ctrl+c也无法停止该过程。

Answer 1

不幸的是，这是u-boot期望在树莓派上启动的方式与QEMU支持该板的二进制启动方式之间的不兼容。

QEMU通常支持两种在Arm上启动来宾代码的方式：

1. Linux内核；这些启动与预期的该主板上内核的启动协议是。对于raspi这将是“启动主CPU，但将辅助CPU放入笔在mbox上等待。”实际上，QEMU模拟了一个很少的固件，足以启动Linux。

2. 不是Linux内核；这些被引导，好像它们是首先要在原始硬件上执行，也就是说所有CPU立即开始执行，这是来宾代码以提供辅助CPU的所有功能它想做。也就是说，您的访客代码必须完成工作固件，因为它实际上是固件。

如果您是原始映像，我们假设您是Linux内核，或合适的uImage。如果您是ELF图片，我们认为您是不是Linux内核。 （这并不完全理想，但我们要出于向后兼容的原因，它在某种程度上不高兴。）

在树莓派板上，期望启动u-boot二进制文件的方式很可能是“就像固件启动了它一样”，这与QEMU支持的两个选项都不完全相同。这种不匹配往往会导致u-boot崩溃（通常是因为它不期望“所有CPU都立即运行”的行为）。

修复程序可能需要更改u-boot以便可以处理QEMU启动它的方式，也可以更改QEMU以支持该板固件的更多仿真（上游QEMU不愿意接受。） >

如果不需要特别使用raspi板，则另一种方法是使用其他板，例如'virt'板，u-boot可以处理这种板，从而使其可以在QEMU上启动。 （“ virt”板还具有更好的设备支持；例如，它可以进行网络连接和USB设备，而“ raspi”和“ raspi2”目前无法执行。）