3

I'm trying to emulate the reMarkable tablet with Qemu in order to create a proper development environment for it, instead of cross-compiling and sending to the hardware device.

The firmware flasher repo contains the rootfs, kernel, DTB and u-boot files. I've created an .img file from the rootfs in order to boot it in Qemu with the following command:

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

but the kernel does not seem to be starting as I have the same log whether the floppy.img file (drive+device) is given or not. The startup loops on this error:

[    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)

full log here

I will update this question when I have new findings, but i'm new to Qemu and I'm quite stuck and ran out of options. The repository i'm working in is here. Thanks for any input !

Pierre-Alexis Ciavaldini
  • 3,369
  • 1
  • 14
  • 16
  • Hi Pierre-Alexis, I looked at your repo at https://git.iostud.io/pciavald/remarkable-dev -- how much of the reMarkable emulator is currently actually working? – Lars Blumberg May 24 '21 at 21:37
  • 1
    Hi Lars, it's starting to date a bit and i have been busy with other things since then, but as far as I recall, it was working at the time. May need some adjusting as I think the reMarkable team has made a lot of updates. The discord server is a good place to find help. – Pierre-Alexis Ciavaldini Jun 16 '21 at 09:03

1 Answers1

6

I haven't investigated too closely, but the fact that the backtrace shows a hang in the imx_rng_init function suggests that the problem is that QEMU doesn't have an emulation of the imx SoC's builtin RNG device, and so the guest is hanging forever waiting for a response from hardware that doesn't exist.

You'll need to either implement a model of that device, or else use a guest kernel which doesn't try to probe for that device.

More generally, running an Arm kernel that's intended for one piece of hardware on a different piece of hardware will usually not work. The sabrelite has the same SoC here, so booting works better than it would if you tried to do it with an entirely unrelated QEMU machine, but if at any time your guest code tries to access hardware outside the SoC which is specific to the reMarkable then you will find it doesn't work. If you really need to get the stock kernel for the hardware to boot you will probably at some point need to bite the bullet and implement a proper machine model of it in QEMU with the relevant devices present.

If you don't actually need to run anything on the guest that cares about the specific differences between one imx6 system and another, you might be able to get away with using a kernel and DTB for the sabrelite board plus the rootfs from the reMarkable.

Peter Maydell
  • 9,707
  • 1
  • 19
  • 25
  • 2
    Thank you for your insight. I've noted a tutorial to create a a Qemu machine, if I had a complete documentation of the board or the help of a reMarkable hardware dev it could be doable. But in the meantime, I'll try to run a "vanilla" imx6 kernel with the reMarkable rootfs, as it is very possible that the e-ink screen embedded in the reMarkable tablet is in cause, and i don't really need it if I can find a way to emulate the screen (may be hard because of their proprietary code to make it more responsive). I'll keep my question updated, if you have any resource I'll gladly read them. – Pierre-Alexis Ciavaldini Sep 06 '19 at 11:31