Kobo Aura ONE (N709) Recovery: Reverse-Engineering, U-Boot Fastboot, Booti & Mark 6

[malodayi]

Dear forum,

I am a newly joined owner of a recently bricked KA1. Disclaimer, I am not a bona fide developer/engineer but an extremely dogged tinkerer who is way out of his depth.

I've been trying to recover this bricked KA1 (N709 / E70Q00) via its U-Boot fastboot implementation. Since the normal recovery paths are dead and there is no raw µSD image available for this specific model, I've had to dig into hex extractions, U-Boot string analysis, and custom initramfs experiments. Since I am way out of my league, I got help from 3 different LLMs, cross-checking findings.

Since the workbench notes and logs were getting extremely chaotic, I also asked one of the LLMs to organize, format, and structure findings into the readable diagnostic report below. So the text between the spoiler tags is an llm output but...

Please note that all the experiments, hex values, CRC checks, mkbootimg parameters, and U-Boot extractions are from my actual hardware tests—no AI hallucinations here. I'm hoping some of the Mark 6 experts here can point me in the right direction regarding Netronix's booti implementation and native bootargs.

Spoiler:

Kobo Aura ONE (N709 / E70Q00) — recovery/reverse-engineering effort, looking for Mark 6 reference images and boot-path help

Device: Kobo Aura ONE, N709, board E70Q00 ("Daylight"), mx6sl-ntx, i.MX6SL, 7.8" 1872×1404 Carta panel.

Previously working Aura ONE that stopped completing its normal boot after being left idle for about 25 days. It had been fully charged and fully working/synced beforehand, with no physical damage.

The normal recovery path is unavailable and there is no known complete raw/µSD image for N709. I have now reached the point where I can reproduce and inspect much of the N709 boot chain, but there is one critical gap: I can deliver a native E70Q00 kernel to the device through its real fastboot implementation, but I cannot yet prove that the kernel reaches my custom initramfs /init.

What is confirmed

* The device is an N709 / E70Q00 / Daylight / mx6sl-ntx / i.MX6SL.
* It reliably appears in NXP/Freescale SDP as "i.MX6SL NTX Smart Device".
* It also has a genuine functional U-Boot fastboot mode, VID_18D1 / PID_0D02, serial N709730086207.
* fastboot version reports 0.5.
* getvar product/version/serialno work; several modern getvar/oem commands do not.
* fastboot reboot recovery works.
* fastboot boot accepts arbitrary RAM boot images and reports:
Sending 'boot.img' ... OKAY
Booting ... OKAY

I extracted the official Aura ONE 4.38.23697 firmware. Its native E70Q00 uImage is a legacy ARM U-Boot image with:

```
Load Address: 0x10000000
Entry Point: 0x10008000
```

The same 0x10008000 kernel entry/load address is present in the original 2016 Aura ONE 4.0.7523 kernel.

I have inspected the 2016 and 2021 E70Q00 kernels in detail. Both are legacy ARM uImages using the same 0x10008000 kernel load/entry address.

I also compared the native USB gadget modules across the firmware generations. In particular, the 2016 and current g_file_storage.ko files are bit-for-bit identical, so there is no evidence that we are dealing with a firmware-generation mismatch in that driver.

The native g_ether.ko and g_file_storage.ko report:

```
vermagic=3.0.35+ preempt mod_unload modversions ARMv7 p2v8
```

and contain CONFIG_MODVERSIONS __versions data. I have not yet independently established the corresponding kernel-side CRC table to the standard Module.symvers/System.map level of proof, so I am deliberately leaving module CRC compatibility as an open question.

The E70Q00 driver tree also contains:

```
drivers/mx6sl-ntx/usb/gadget/arcotg_udc.ko
```

but this particular file is 0 bytes. The only non-empty arcotg_udc.ko I found in the firmware is an older 2.6.35-era Freescale module and does not match the E70Q00 3.0.35 kernel. I currently suspect the 0-byte platform file is a placeholder for functionality built into the kernel, but that part is not proven.

What I have tried

I built four native-kernel diagnostic boot images around the real E70Q00 uImage, wrapped in a legacy Android boot-image container using:

```
base 0x10000000
kernel_offset 0x00008000
ramdisk_offset 0x01000000
tags_offset 0x00000100
pagesize 2048
header_version 0
```

#01:
BusyBox init attempted to load g_file_storage against /dev/mmcblk0, read-only.

#02:
BusyBox init mounted proc/sys/devtmpfs and attempted to toggle anything exposed under /sys/class/leds.

#03:
BusyBox init loaded the native g_ether.ko without touching eMMC.

#04:
BusyBox init did nothing except:

```
sleep 15
reboot -f
```

I also kept the exact 0-byte Aura ONE arcotg_udc.ko placeholder in #04 but did not load it.

#02 and #03 produced an immediate Windows disconnect after fastboot boot, but later I discovered that the Kobo's fastboot session can also time out/disappear on its own after inactivity. Therefore the USB disconnect is not proof that Linux took control.

#04 likewise produced:

```
Booting OKAY
immediate fastboot USB disconnect
i.MX6SL NTX Smart Device became disconnected/pale
no second USB event
no LED change
no observable reboot after more than a minute
```

This leaves /init execution unresolved.

The most interesting new finding: the actual E70Q00 U-Boot

I extracted and inspected the 4.38.23697 E70Q00 U-Boot binary:

```
u-boot_lpddr2_512-E70Q00-LPDDR2.bin
```

It identifies itself as:

```
U-Boot 2009.08-00078-ga6e1746-dirty-svn
(29 2016 - 14:05:20)
```

This is the real Netronix/Kobo bootloader, not a generic modern U-Boot.

It contains a dedicated Android boot command:

```
booti - boot android bootimg from memory
```

and the fastboot path includes:

```
fastboot_dev
booti ${fastboot_dev}
```

It also contains Android/boot command-line handling strings such as:

```
androidboot.serialno=
bootargs
setenv bootargs %s %s
setenv bootargs ${bootargs} %s
```

and a Kobo-specific check:

```
[ERROR] kernel cmdline 'root=' not /dev/mmcblk !!
```

The normal native boot environment contains:

```
bootargs_base=setenv bootargs console=ttymxc0,115200 rootwait rw no_console_suspend
bootcmd_mmc=run bootargs_base bootargs_mmc;load_ntxkernel; bootm
bootcmd_SD=run bootargs_base bootargs_SD;load_ntxkernel; bootm
bootcmd_recovery=run bootargs_base bootargs_recovery;load_ntxkernel; bootm
```

The important unresolved question is therefore:

Does this particular Netronix booti/fastboot path really pass the Android boot image cmdline through to the Linux kernel as ATAG_CMDLINE, or does it construct/modify bootargs itself?

This may be the key to why all our custom ramdisks appear inert.

What I'm looking for

1. A complete raw µSD image for a close Mark 6 sibling, particularly:

Kobo N236 Aura Edition 2 V1
Kobo N236 Aura Edition 2 V2
Kobo N437 Glo HD

These are interesting because complete images are known to exist for them, unlike N709. I'm not proposing to flash any of these onto the Aura ONE.

The purpose would be comparative analysis:

```
U-Boot
partition layout
kernel
hwconfig
waveform
rootfs
rcS/inittab
udev rules
USB initialization
exact bootargs
```

The Aura ONE firmware itself bundles several E60Q/E70Q Mark 6 kernels/U-Boots, so I suspect a working sibling image could tell us much more about the common Netronix boot path than continuing to guess from the N709 update package alone.

2. Anyone with a working N709 Aura ONE who can provide any of the following:

raw eMMC dump
partition dump
boot partition dump
native bootloader environment
bootargs/environment dump
UART boot log

Even a partial dump would be useful if the person does not want to publish a complete image.

3. Anyone who has actually used fastboot boot with a custom Linux/initramfs on an NTX/i.MX6SL Kobo or Tolino.

In particular, I'd like to know whether this old Netronix U-Boot's "booti" passes the Android header cmdline to the kernel, and whether there is a known working cmdline for these devices.

4. Mainline/devicetree work around Mark 6 NTX/i.MX6SL devices.

There is Linux/mainline work for a number of related Kobo/Tolino boards, but I have not found a working N709/E70Q00 device tree. A working DTS for a close sibling could be extremely useful even if it cannot be used unchanged on the Aura ONE.

What I'm specifically trying to avoid is blind cross-flashing. The goal is to use known-good Mark 6 hardware/software as a reference to reconstruct the missing N709 recovery path.

I can provide the exact boot-image construction, raw kernels, module binaries, firmware file lists, U-Boot binary and experiment log to anyone who wants to inspect them.

Any information about N236/N437/E60Q90/E60QL0/E70Q00 relationships, Netronix fastboot/booti behavior, or existing Mark 6 kernel/DTS work would be particularly useful.