linux - Qemu 引导原始内核镜像(不是 ELF)

Question

有没有办法说服 qemu(qemu-system-mipsel v4.1.0，如果重要的话)加载为(古老的)u-boot 构建的二进制(非 elf)镜像？

我尝试了我的 uImage 和 vmlinux.bin，但我总是得到“图像不是 ELF”

完整的命令行是:

qemu-system-mipsel -M malta -kernel output/images/vmlinux.bin -serial stdio -drive file=output/images/rootfs.ext2,format=raw -append "rootwait root=/dev/hda" -net nic,model=pcnet -net user

错误是:

qemu-system-mipsel: could not load kernel 'output/images/vmlinux.bin': The image is not ELF

...这是绝对正确的!该图像(它的 uImage 对应部分，实际上)在真实目标上运行良好(与 Malta 非常相似，但这超出了重点；失败的内核将是一个完全不同的问题)使用(在 u-启动)像这样的东西:

usb reset; fatload usb 0 85000000 uImage; fatload usb 0 86000000 initram.cpio.xz; setenv bootargs rd_start=0x86000000 rd_size=15000000 USE=usb; bootm 85000000

如前所述:我的问题是 qemu 甚至没有尝试加载图像，而不是它在运行时失败。

什么是正确的咒语？

Answer 1

您可能必须使用 -bios 标志来提供 U-boot 镜像，然后自己设置环境以将其交给内核。根据我的理解，QEMU 要求将 ELF 格式的图像提供给 -kernel 标志，大概是因为 ELF header 中包含的数据是配置环境所必需的(特别强调这个词)真正的引导加载程序(因为您有效地绕过了该引导阶段并直接跳转到内核执行)。 -bios 没有这些要求，因为您可能不会看到使用 ELF header 的第一阶段二进制文件。

如果您知道内核镜像的入口点，这似乎是您基于 uboot 命令所做的，您可以将 -bios 标志与 -device 结合使用loader,addr=[入口点],cpu-num=0。但是，如果您的硬件中存在任何 MMU、TLB 或其他架构特定的寻址，您可能会遇到问题。

对所有这些持怀疑态度，因为我只是在利用我通过与您类似的事情获得的知识来工作。可能有更好的方法。