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

malodayi · 08-23-2026, 11:11 AM

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:

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.

clydecoutinho · 08-28-2026, 09:21 AM

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.

geek1011 · 08-28-2026, 03:46 PM

These posts are nearly incomprehensible, and I suspect both were entirely LLM-written. This is not to diminish the efforts of the human behind them, but whatever the point is, it could be conveyed much more clearly.

There are a few fragments of actually useful info in these posts, but it's not clear what the goal or result was, nor what exactly you mean by "bricked", nor how someone would continue whatever it is you are trying to do here...

geek1011 · 08-28-2026, 04:04 PM

Upon re-reading it multiple times, I think I understand the following:

Both of you tried to make a kernel+initramfs boot image out of the 4.38.23697 kernel and various /init payloads which perform different actions (USBMS, LED, ethernet, reboot, watchdog).
All attempts were inconclusive after fastboot success (and you didn't provide any indication in the post nor to your LLMs to concretely distinguish failures).
Your LLMs have been guessing at the boot image format mostly blindly, which may have resulted in the inconclusive results.
The kernel cmdline may or may not be correct.

Neither of you have provided:

What actually happens to the device when attempting to turn it on, nor what you consider "bricked" to be.
UART logs.
What state the "idle" device was in (was it plugged in? lights?).
What the screen is showing now, and what the screen was showing before and after it was "idle".
Actual concrete information about booti.
Whether you have your own flash dumps we can look at.
Your test boot images, and how you created them.
Your host tooling, versions, platform, etc.

I also recommend looking at ntx_hwconfig (both the partition and the tool).

Also, malodayi, your (or the LLM's) original notes and logs would be much more useful than whatever that summary is supposed to be.

malodayi · 09-02-2026, 06:24 AM

@clydecoutinho
Thank you for your reply. I will continue working on this with the help of a forum member and planning to post whatever developments I have. Hope we will get trough this.

@geek1011
You're almost completely right on my post. As I am not a genuine engineer but a thinkerer turned designer I needed help from LLMs and believe me I am no fan of them or the slop. So I am really sorry if my efforts added to the slop. I will try to add details you mentioned as far as my abilities allow.

- I specifically pointed the part that was generated by the LLM but you're right that that's the bulk of it.
- By bricked what I meant was, my beloved KA1 (after not using it for a short while) was stuck on the cover of the last book I was reading, and a “power off” overlay on a small portion of the cover. When I tried to turn on, the RGB LED slowly blinked with blue color and nothing happened, the device didn’t turn on. As I was at the beach at that moment, I tried a reasonable amount times (like 50) before I gave up. When I got back to the place I was staying I tried first the same thing and then tried long pressing while connected to the power. There were a couple of red blinks too but nothing more. I thought it was a failure originated from the battery so I left it plugged for 8 hours or so. After that the long press without power produced nothing new but the colors produced by the RGB LED changed when plugged. After the blue slow blink there came rapid red and green blinks. The backlight of the screen turned on but nothing else. U tried the same with different chargers,/cables, connecting to macs and pc’s instead of wall plugs etc. before turning on to google, reddit, kobo faq’s, this forum and the LLMs as a last resort. This is what I mean by bricked.  
* Both of you tried to make a kernel+initramfs boot image out of the 4.38.23697 kernel and various /init payloads which perform different actions (USBMS, LED, ethernet, reboot, watchdog).
- Yes I tried to get any type reaction from the device to understand if I was encountering with a hw failure or a corrupted logic. As I am a mac user of 30 years the old HFS+ seasoned my to logic failures especially in the early days.

* All attempts were inconclusive after fastboot success (and you didn't provide any indication in the post nor to your LLMs to concretely distinguish failures).
- Exactly
* Your LLMs have been guessing at the boot image format mostly blindly, which may have resulted in the inconclusive results.
- I can concur this guess exactly and sadly about the LLMs I tried but I had nothing more to work with at the time and I don’t like giving up.
* The kernel cmdline may or may not be correct.
- Exactly

Neither of you have provided:
* What actually happens to the device when attempting to turn it on, nor what you consider "bricked" to be.
- That is a big mistake on my side, I had lost the perspective for a good reporting after long hours of blind trying without much knowledge
* UART logs.
- I was not at my place so my abilities were even more limited they already are. So I didn’t pry open the device and try locate the UART pins.
* What state the "idle" device was in (was it plugged in? lights?).
* What the screen is showing now, and what the screen was showing before and after it was "idle".
- The device when I don’t meddle with it is without any indication from the LED and the backlight is off. The screen still has the cover on it. The screen didn’t show anything different at all since AK1 is “bricked”
* Actual concrete information about booti.
- This question is beyond my ability to give a good answer without an LLM interfering but since that was the reason of your complaint to begin with I will not try to get an information from those.
* Whether you have your own flash dumps we can look at.
* Your test boot images, and how you created them.
- I can share those if you like, I didn’t know the kind of reply I would get so tried to keep the initial post as short as I could.
* Your host tooling, versions, platform, etc.
- Not sharing those may be the stupidest thing I did. I should know at least that much about debugging. I created the custom images on an M1 / sonoma Mac and did the fastboot&sending of images on a windows10 Lenovo laptop (that a family member owns). The reason to use two different machines were the USBC ports on the mac, the need to use a converter and Apple’s strict management on the data transferred trough those ports in their infinite wisdom🤦🏻*♂️🤦🏻*♂️🤦🏻*♂️

* I also recommend looking at ntx_hwconfig (both the partition and the tool).
- I will check that as soon as I can return to this adventure.

* Also, malodayi, your (or the LLM's) original notes and logs would be much more useful than whatever that summary is supposed to be
- Believe it would be 80 pages of back and forth of four idiots (the LLMs and me). I let the LLMs generate the report and tried to edit myself, albeit miserabl, as I understand. But I should have done a much better job.

Thank you so very much for your detailed reply. I will try to do much better both on this adventure and my further posts in the forum.    Sadly I had to stop looking at this for (hopefully) a short while as I am dealing with a health emergency of a family member. But I hope to return to this as soon as I can. I am a firm believer of right to repair and enjoy trying to revive/revitalise devices as I can’t do that for people.

This post is completely hand written and I am truly grateful for your replies.

embryo · 09-02-2026, 05:51 PM

Just a silly question, but
How did you rule out a broken screen?

malodayi · 09-02-2026, 08:17 PM

Not a completely silly one =)
I didn’t and can’t be sure, until I can be sure everything else is working.

But there are a couple of omens pointing at the direction I suspect:
- There is no physical damage on the screen,
- It is much more common for the data/structure of a storage device to be corrupted than the screen flaking (in my limited view)
- The LED indicator is behaving bizarrely and very differently from the normal operation flow
- And, maybe the most importantly, when connected to the computer the FAT32 partition of the eMMC doesn’t mount at all.

Now, if you’re satisfied with this explanation the immediate next question is “How did you rule out an electrically dead eMMC?” That is much harder to rule out, in my opinion, and still not sure if that is the case, just hoping it is not

08-23-2026, 11:11 AM	#1
malodayi Junior Member Posts: 5 Karma: 10 Join Date: Aug 2026 Device: Kobo Aura One	Kobo Aura ONE (N709) Recovery: Reverse-Engineering, U-Boot Fastboot, Booti & Mark 6 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.

08-28-2026, 04:04 PM	#4
geek1011 Wizard Posts: 2,842 Karma: 7454319 Join Date: May 2016 Location: Ontario, Canada Device: Kobo Mini, Aura Edition 2 v1, Clara HD, Clara BW, Libra Colour	Upon re-reading it multiple times, I think I understand the following: Both of you tried to make a kernel+initramfs boot image out of the 4.38.23697 kernel and various /init payloads which perform different actions (USBMS, LED, ethernet, reboot, watchdog). All attempts were inconclusive after fastboot success (and you didn't provide any indication in the post nor to your LLMs to concretely distinguish failures). Your LLMs have been guessing at the boot image format mostly blindly, which may have resulted in the inconclusive results. The kernel cmdline may or may not be correct. Neither of you have provided: What actually happens to the device when attempting to turn it on, nor what you consider "bricked" to be. UART logs. What state the "idle" device was in (was it plugged in? lights?). What the screen is showing now, and what the screen was showing before and after it was "idle". Actual concrete information about booti. Whether you have your own flash dumps we can look at. Your test boot images, and how you created them. Your host tooling, versions, platform, etc. I also recommend looking at ntx_hwconfig (both the partition and the tool). Also, malodayi, your (or the LLM's) original notes and logs would be much more useful than whatever that summary is supposed to be. Last edited by geek1011; 08-28-2026 at 04:07 PM.

09-02-2026, 08:17 PM	#7
malodayi Junior Member Posts: 5 Karma: 10 Join Date: Aug 2026 Device: Kobo Aura One	Not a completely silly one =) I didn’t and can’t be sure, until I can be sure everything else is working. But there are a couple of omens pointing at the direction I suspect: - There is no physical damage on the screen, - It is much more common for the data/structure of a storage device to be corrupted than the screen flaking (in my limited view) - The LED indicator is behaving bizarrely and very differently from the normal operation flow - And, maybe the most importantly, when connected to the computer the FAT32 partition of the eMMC doesn’t mount at all. Now, if you’re satisfied with this explanation the immediate next question is “How did you rule out an electrically dead eMMC?” That is much harder to rule out, in my opinion, and still not sure if that is the case, just hoping it is not Last edited by malodayi; 09-02-2026 at 08:22 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Bootloop on Page after fastboot boot custom recovery.	Anghirrim	Onyx Boox	47	05-26-2024 12:50 PM
Reverse Engineering Conversion	Conday	Conversion	6	09-16-2021 10:11 AM
K4 sync reverse engineering	xifer	Kindle Developer's Corner	3	10-16-2020 10:03 AM
reverse engineering azw3r?	blaenk	Kindle Developer's Corner	6	04-17-2016 03:53 AM
Reverse Engineering Whispersync	Fmstrat	Kindle Developer's Corner	3	01-02-2013 03:59 PM

08-28-2026, 09:21 AM	#2
clydecoutinho Junior Member Posts: 1 Karma: 12 Join Date: Aug 2026 Device: Kobo Aura One	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.

08-28-2026, 03:46 PM	#3
geek1011 Wizard Posts: 2,842 Karma: 7454319 Join Date: May 2016 Location: Ontario, Canada Device: Kobo Mini, Aura Edition 2 v1, Clara HD, Clara BW, Libra Colour	These posts are nearly incomprehensible, and I suspect both were entirely LLM-written. This is not to diminish the efforts of the human behind them, but whatever the point is, it could be conveyed much more clearly. There are a few fragments of actually useful info in these posts, but it's not clear what the goal or result was, nor what exactly you mean by "bricked", nor how someone would continue whatever it is you are trying to do here...

09-02-2026, 06:24 AM	#5
malodayi Junior Member Posts: 5 Karma: 10 Join Date: Aug 2026 Device: Kobo Aura One	@clydecoutinho Thank you for your reply. I will continue working on this with the help of a forum member and planning to post whatever developments I have. Hope we will get trough this. @geek1011 You're almost completely right on my post. As I am not a genuine engineer but a thinkerer turned designer I needed help from LLMs and believe me I am no fan of them or the slop. So I am really sorry if my efforts added to the slop. I will try to add details you mentioned as far as my abilities allow. - I specifically pointed the part that was generated by the LLM but you're right that that's the bulk of it. - By bricked what I meant was, my beloved KA1 (after not using it for a short while) was stuck on the cover of the last book I was reading, and a “power off” overlay on a small portion of the cover. When I tried to turn on, the RGB LED slowly blinked with blue color and nothing happened, the device didn’t turn on. As I was at the beach at that moment, I tried a reasonable amount times (like 50) before I gave up. When I got back to the place I was staying I tried first the same thing and then tried long pressing while connected to the power. There were a couple of red blinks too but nothing more. I thought it was a failure originated from the battery so I left it plugged for 8 hours or so. After that the long press without power produced nothing new but the colors produced by the RGB LED changed when plugged. After the blue slow blink there came rapid red and green blinks. The backlight of the screen turned on but nothing else. U tried the same with different chargers,/cables, connecting to macs and pc’s instead of wall plugs etc. before turning on to google, reddit, kobo faq’s, this forum and the LLMs as a last resort. This is what I mean by bricked.   * Both of you tried to make a kernel+initramfs boot image out of the 4.38.23697 kernel and various /init payloads which perform different actions (USBMS, LED, ethernet, reboot, watchdog). - Yes I tried to get any type reaction from the device to understand if I was encountering with a hw failure or a corrupted logic. As I am a mac user of 30 years the old HFS+ seasoned my to logic failures especially in the early days. * All attempts were inconclusive after fastboot success (and you didn't provide any indication in the post nor to your LLMs to concretely distinguish failures). - Exactly * Your LLMs have been guessing at the boot image format mostly blindly, which may have resulted in the inconclusive results. - I can concur this guess exactly and sadly about the LLMs I tried but I had nothing more to work with at the time and I don’t like giving up. * The kernel cmdline may or may not be correct. - Exactly Neither of you have provided: * What actually happens to the device when attempting to turn it on, nor what you consider "bricked" to be. - That is a big mistake on my side, I had lost the perspective for a good reporting after long hours of blind trying without much knowledge * UART logs. - I was not at my place so my abilities were even more limited they already are. So I didn’t pry open the device and try locate the UART pins. * What state the "idle" device was in (was it plugged in? lights?). * What the screen is showing now, and what the screen was showing before and after it was "idle". - The device when I don’t meddle with it is without any indication from the LED and the backlight is off. The screen still has the cover on it. The screen didn’t show anything different at all since AK1 is “bricked” * Actual concrete information about booti. - This question is beyond my ability to give a good answer without an LLM interfering but since that was the reason of your complaint to begin with I will not try to get an information from those. * Whether you have your own flash dumps we can look at. * Your test boot images, and how you created them. - I can share those if you like, I didn’t know the kind of reply I would get so tried to keep the initial post as short as I could. * Your host tooling, versions, platform, etc. - Not sharing those may be the stupidest thing I did. I should know at least that much about debugging. I created the custom images on an M1 / sonoma Mac and did the fastboot&sending of images on a windows10 Lenovo laptop (that a family member owns). The reason to use two different machines were the USBC ports on the mac, the need to use a converter and Apple’s strict management on the data transferred trough those ports in their infinite wisdom🤦🏻♂️🤦🏻♂️🤦🏻♂️ I also recommend looking at ntx_hwconfig (both the partition and the tool). - I will check that as soon as I can return to this adventure. * Also, malodayi, your (or the LLM's) original notes and logs would be much more useful than whatever that summary is supposed to be - Believe it would be 80 pages of back and forth of four idiots (the LLMs and me). I let the LLMs generate the report and tried to edit myself, albeit miserabl, as I understand. But I should have done a much better job. Thank you so very much for your detailed reply. I will try to do much better both on this adventure and my further posts in the forum.    Sadly I had to stop looking at this for (hopefully) a short while as I am dealing with a health emergency of a family member. But I hope to return to this as soon as I can. I am a firm believer of right to repair and enjoy trying to revive/revitalise devices as I can’t do that for people. This post is completely hand written and I am truly grateful for your replies.

09-02-2026, 05:51 PM	#6
embryo Fanatic Posts: 540 Karma: 64554 Join Date: Aug 2013 Device: Kobo Glo, GloHD	Just a silly question, but How did you rule out a broken screen?