arm - 使用 Qemu 模拟 reMarkable 平板电脑 (i.MX6 ARMv7)

Question

我正在尝试模拟 reMarkable tablet使用 Qemu 为其创建合适的开发环境，而不是交叉编译并发送到硬件设备。

firmware flasher repo包含 rootfs、内核、DTB 和 u-boot 文件。我已经从 rootfs 创建了一个 .img 文件，以便使用以下命令在 Qemu 中启动它:

qemu-system-arm \
  -M sabrelite \
  -bios "files/u-boot.imx" \
  -kernel "zImage" \
  -append "console=ttymxc0 rootfstype=ext4 root=/dev/mmcblk1p2 rw rootwait init=/bin/bash loglevel=8 bootmem-debug earlyprintk" \
  -dtb "zero-gravitas.dtb" \
  -drive file="floppy.img",format=raw,id=mmcblk1p2 \
  -device sd-card,drive=mmcblk1p2

但内核似乎没有启动，因为无论是否提供了 floppy.img 文件(驱动器+设备)，我都有相同的日志。启动循环出现此错误:

[    0.713093] 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 19, base_baud = 5000000) is a IMX
[    0.732268] console [ttymxc0] enabled
[    0.736333] phy index low: 1, phy index high: 2
[  240.289647] INFO: task swapper:1 blocked for more than 120 seconds.
[  240.290160]       Not tainted 4.1.28-zero-gravitas-01866-ge0b823726ea4-dirty #82
[  240.290318] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.290662] swapper         D 8051c44c     0     1      0 0x00000000
[  240.292245] [<8051c44c>] (__schedule) from [<8051c73c>] (schedule+0x40/0x98)
[  240.292473] [<8051c73c>] (schedule) from [<8051e7b8>] (schedule_timeout+0x114/0x168)
[  240.292781] [<8051e7b8>] (schedule_timeout) from [<8051d248>] (wait_for_common+0x88/0x130)
[  240.292953] [<8051d248>] (wait_for_common) from [<80262c74>] (imx_rng_init+0x158/0x2a8)
[  240.293117] [<80262c74>] (imx_rng_init) from [<80262574>] (set_current_rng+0xc0/0x15c)
[  240.293276] [<80262574>] (set_current_rng) from [<80262874>] (hwrng_register+0x190/0x1b8)
[  240.293436] [<80262874>] (hwrng_register) from [<807c3fd8>] (imx_rng_probe+0xd4/0x134)
[  240.293682] [<807c3fd8>] (imx_rng_probe) from [<802748e0>] (platform_drv_probe+0x44/0xac)
[  240.293852] [<802748e0>] (platform_drv_probe) from [<802735ac>] (driver_probe_device+0x178/0x2b8)
[  240.294009] [<802735ac>] (driver_probe_device) from [<802737bc>] (__driver_attach+0x8c/0x90)
[  240.294158] [<802737bc>] (__driver_attach) from [<80271d50>] (bus_for_each_dev+0x68/0x9c)
[  240.294352] [<80271d50>] (bus_for_each_dev) from [<802726bc>] (bus_add_driver+0x13c/0x1e4)
[  240.294600] [<802726bc>] (bus_add_driver) from [<80273ed4>] (driver_register+0x78/0xf8)
[  240.294843] [<80273ed4>] (driver_register) from [<807c434c>] (__platform_driver_probe+0x20/0x70)
[  240.295092] [<807c434c>] (__platform_driver_probe) from [<807a9d78>] (do_one_initcall+0x118/0x1c4)
[  240.295367] [<807a9d78>] (do_one_initcall) from [<807a9f48>] (kernel_init_freeable+0x124/0x1c4)
[  240.295609] [<807a9f48>] (kernel_init_freeable) from [<8051883c>] (kernel_init+0x8/0xe8)
[  240.295844] [<8051883c>] (kernel_init) from [<8000ef88>] (ret_from_fork+0x14/0x2c)

完整日志 here

当我有新发现时，我会更新这个问题，但我是 Qemu 的新手，我很困惑，没有选择。我正在使用的存储库是 here .感谢您的任何输入!

Answer 1

我没有仔细调查，但回溯显示 imx_rng_init 函数挂起的事实表明问题在于 QEMU 没有对 imx SoC 的内置 RNG 设备的仿真，因此 guest 是永远挂起等待来自不存在的硬件的响应。

您需要实现该设备的模型，或者使用不尝试探测该设备的访客内核。

更一般地说，在不同的硬件上运行专用于一个硬件的 Arm 内核通常是行不通的。 sabrelite 在此处具有相同的 SoC，因此启动比您尝试使用完全不相关的 QEMU 机器启动时效果更好，但是如果您的访客代码在任何时候尝试访问特定于 reMarkable 的 SoC 之外的硬件，那么你会发现它不起作用。如果您确实需要获取用于硬件启动的库存内核，您可能在某个时候需要咬紧牙关并在 QEMU 中使用相关设备实现适当的机器模型。

如果你实际上不需要在 guest 上运行任何关心一个 imx6 系统和另一个系统之间的具体差异的东西，你可能能够为 sabrelite 板使用内核和 DTB 加上来自非凡的。