qemu - 如何在QEMU(raspi2)上运行u-boot？

Question

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

这是我尝试过的:

1. 安装 Ubuntu 18.04 WSL2在 Windows 上。

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 内核；这些启动与任何预期该板上内核的启动协议(protocol)是。对于树莓派这将是“启动主 CPU，但将辅助 CPU 放入笔在 mbox 上等待”。实际上，QEMU 模拟了固件的数量非常少，足以启动 Linux。

2. 不是 Linux 内核；这些被启动，就好像它们是首先要在原始硬件上执行，也就是说所有 CPU 立即开始执行，这是 guest 代码提供辅助 CPU 的任何设置它想做。也就是说，您的访客代码必须完成这项工作此处的固件，因为它实际上是固件。

如果您是原始镜像，我们假设您是 Linux 内核，或合适的 uImage。如果您是 ELF 图像，我们假设您是不是 Linux 内核。 (这并不完全理想，但我们要由于向后兼容性的原因，在某种程度上它显得很笨拙。)

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

修复需要对 u-boot 进行更改，以便它可以按照 QEMU 启动它的方式处理启动，或者对 QEMU 进行更改以支持对该板固件的更多模拟(QEMU 上游将不愿意接受)。

如果不需要特别使用 raspi 板，另一种方法是使用其他一些板，例如 u-boot 确实以允许在 QEMU 上启动的方式处理的“virt”板。 (“virt”板还具有更好的设备支持；例如，它可以执行网络和 USB 设备，而“raspi”和“raspi2”目前还无法做到这一点。)