我正在尝试使用 Qemu模拟reMarkable 平板电脑，以便为其创建合适的开发环境，而不是交叉编译并发送到硬件设备。
该固件闪光回购包含了根文件系统，内核，DTB和u-boot的文件。我已经.img从 rootfs创建了一个文件，以便使用以下命令在 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)
完整日志在这里
当我有新的发现时，我会更新这个问题，但我是 Qemu 的新手，我很困惑并且没有选择。我正在工作的存储库在这里。感谢您提供任何意见！
我没有仔细研究过，但是回溯显示 imx_rng_init 函数挂起的事实表明问题在于 QEMU 没有对 imx SoC 的内置 RNG 设备的仿真，因此来宾一直在等待对于来自不存在的硬件的响应。
您需要实现该设备的模型，或者使用不会尝试探测该设备的访客内核。
更一般地说，在另一块硬件上运行用于一个硬件的 Arm 内核通常是行不通的。sabrelite 在这里具有相同的 SoC，因此启动效果比您尝试使用完全不相关的 QEMU 机器启动时更好，但是如果您的访客代码在任何时候尝试访问特定于 reMarkable 的 SoC 之外的硬件，那么你会发现它不起作用。如果您真的需要获取用于启动硬件的库存内核，您可能在某个时候需要硬着头皮在 QEMU 中使用相关设备实现正确的机器模型。
如果您实际上不需要在来宾上运行任何关心一个 imx6 系统与另一个系统之间的特定差异的东西，那么您可能可以避免使用 sabrelite 板的内核和 DTB 以及 reMarkable 中的 rootfs。