Kindle Basic (2014, 7th Gen) Unbricking from "Boy and Tree" splash screen - Debug

[FalconFour]

So, my Kindle Basic (2014) - most similar to PW2 if not almost a direct rebrand of it - decided that instead of rebooting, it'd wedge itself at the "Boy and Tree" splash screen forever last night. I found this thread: https://www.mobileread.com/forums/sh...d.php?t=340387 - which showed what the internals looked like, and with some bezel peeling and a Torx T5 bit, I got to work. My symptom wasn't exactly the same - I had no reason for it not to be working, no flashing, just jailbroken. Most concerningly, I need to know if the extension I'm developing somehow had an effect on it (it doesn't do anything with the rootfs, any flashing, anything crazy - it just downloads a new "screensaver" image on a schedule every several minutes). So what could it be?

Soldered up wires to the "Serial Debug" pads, opened a terminal to the port at 115200 baud, and... I was greeted with open arms:


Cool. The battery is dead. Totally expected, since I left it sitting at boot overnight. This proceeded for a while...



Until eventually, "sufficient charge". Neat.


It proceeded to boot, but... That's not a normal Linux kernel boot log. There was a useful "recovery menu" that I could press a key at, but...



That's where it hangs. Just stuck here forever. OK, let's reset and watch for that recovery menu. I already know it's not the U-Boot "stop autoboot" I'm looking for (that's fine, that'll get me U-Boot, but I don't need that since I have a recovery menu that's offered). So what do we have there?


That's a handy toolkit. That ought to offer everything I need. Printing the buffer gives me the usual Linux boot messages I expect. So, that's attached (kindle-dmesg-log.txt).

Reboot (because it has a timer and I have to write things here, lol), and it gets hung again in the same place.

Sigh. "Export FAT partition"?



Kindle! There you are! The FAT filesystem appears on my PC. I can get my files (and more importantly... logs) off it! And there's no longer any timer counting down in the recovery menu - as long as the USB is mounted (it counts down if it's unplugged).

So, I bring over my Windows laptop (as I trust chkdsk far more than anything Mac can do), and run chkdsk. No errors. I back up the whole FAT volume. No errors.

I exit the recovery menu (reboot), and....?



Well, the console doesn't tell us much, but on-screen is now the happy USB message. Fully booted, connected, back to normal. Odd, the root password isn't blank, as it is over SSH. Probably usbnetwork does something neat there for SSH.

Moral of the story? I don't know. I think MacOS might have automatically/silently repaired the FAT partition when it was first connected. My extension's log file was now 0KB (completely empty), and the reason I rebooted it (at the start of this saga) was that it the log file was 2MB, but "corrupted" - which means the FAT filesystem had cross-links or other corruption (not the file itself), so the file couldn't be read, thus I rebooted. I still can't tell why that happens, but it does tell me I should probably be much more careful about writing log files (maybe write to a RAM-based /tmp folder & periodically copy it to the USB partition?).




But my Kindle is back, and now we've got some more info about the recovery options... if you've got the nerve to solder to those tiny pads.

[FalconFour]

And with that, I've now updated the extension to probe for "userstoreIsAvailable" status before making any writes to its USB (FAT) files, which is a flag that goes to 0 whenever it's plugged-in to USB. Concurrent writes to a FAT volume can, as I've experienced, be fatal. So now the extension avoids those at every level. Could be a useful tip for anyone developing extensions of their own, too.

https://github.com/FalconFour/online...92fec8bddcf751