Question

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

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设备的仿真，因此来宾是永久挂起，等待来自不存在的硬件的响应。

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

更一般而言，在不同硬件上运行旨在用于一个硬件的Arm内核通常将不起作用。 sabrelite在此处具有相同的SoC，因此引导工作比尝试使用完全不相关的QEMU计算机进行引导的工作要好，但是如果您的来宾代码在任何时候尝试访问SoC外部的硬件（特定于reMarkable），则引导会更好您会发现它不起作用。如果确实需要硬件来启动股票内核，则可能需要在某些时候咬紧牙关，并在存在相关设备的QEMU中实现它的正确机器模型。

如果您实际上不需要在客户机上运行任何事情，而不必在乎某个imx6系统与另一个imx6系统之间的特定差异，则可以摆脱使用内核和DTB的sabrelite板以及来自root的rootfs的麻烦。 reMarkable。

使用Qemu模拟可重新标记的平板电脑（i.MX6 ARMv7）

1 个答案: