|
Fellow N709 owner here, hit the identical wall independently this week -- thought I'd add data points since we clearly ran nearly the same experiments.
Confirmed: uImage-E70Q00 and uImage-E60QL0 are byte-identical (same SHA256, same build ID 89399f_#5031) -- one shared kernel across those two variants at least.
We independently tried g_file_storage against the raw disk, g_ether, and LED toggling from a busybox /init -- same result as your #01-#03: clean Booting OKAY, fastboot handoff, then total silence. Also tried: a watchdog-petting variant (in case U-Boot leaves one counting down for Linux to service -- no change), three more kernel variants from the firmware zip (E60Q90, E60QM0A, E60QM0B -- all accepted with clean Booting OKAY, zero difference), and stripping the 64-byte U-Boot legacy header before packaging into the Android boot.img (on the theory booti might not strip it -- also no observable difference).
New data point that might matter for interpretation: we also did the official Kobo factory reset procedure (help.kobo.com's documented "hold until light off, then hold 30s, wait for Restore screen") completely cleanly, with zero fastboot/PC involvement -- no Restore screen ever appears, no visible change at all. If the factory-intended recovery path is equally silent, that points away from "we haven't found the right custom image yet" and toward something the whole boot chain depends on failing before any of this even matters -- worth keeping in mind chasing further kernel/ramdisk permutations.
Also, for anyone else fighting the ~2 second fastboot window: Zadig's "Device -> Create New Device" lets you pre-stage the WinUSB driver for VID 18D1 / PID 0D02 before the device ever connects, rather than racing to catch it live in the device list -- made the connection completely reliable for us. Happy to share our PowerShell tooling (polling-based fastboot catcher, boot scripts, the test ramdisks) or the stripped zImage if useful to anyone.
|