(The majority of our readers are not members - so in cases like this, I try to write for entire audience.)
The SoC has some on-chip, static, RAM and some code in ROM to get things started -
Then it loads and runs u-boot:
Code:
U-Boot 2009.08-lab126 (Aug 05 2014 - 04:37:39)
Which continues with the hardware initialization, including starting the external RAM and eMMC.
Went complete, it pauses before loading and executing the (combined) initramfs kernel and ram file system (what you see in your PC's grub menu as the kernel= and initrd= entries).
The Kindel's u-boot gives you an opportunity (of about 1 to 2 seconds) to stop the load and run of the initramfs and remain in interactive u-boot here:
Code:
Hit any key to stop autoboot: 1 0
If we have to use u-boot in interactive mode, the above is where we stop the sequence.
PS: All of the identification information that u-boot prints out, line 23 - line 30 is specific to the board and not stored in any of the file systems - so keep a copy of this information in case it is ever required to setup the eMMC (or its blank replacement).
The u-boot menu (there are two of them) has an "Erase All" choice - don't try it - it does exactly what the selection says - and then your device is toast unless you have the above information.
(Sometimes, Lab126 has fixed that coding error in some firmware versions.)
So we continue with loading the kernel:
Code:
## Booting kernel from Legacy Image at 80800000 ...
Then executing the kernel
Code:
Starting kernel ...
The kernel has an appended filesystem and some basic applications.
The auto-boot sequence can be interrupted at this point:
Code:
Press [ENTER] for recovery menu... 0
(Since you didn't that and the next message are run together.)
Before doing a switch-root to the on eMMC system, the initramfs checks (and corrects as required) the partitioning and formatting of the eMMC:
Code:
//dev/mmcblk0p4:
CHS=4/16/104512 size=3424649216 bytes
flag type first last lba first lba size
Partition p1:
0x00 0x0b 16 <large> 16 6688752
CHS: 0/1/1 - <large>
Partition p2:
Partition p3:
Partition p4:
Checks the battery charge, and if considered sufficent to flash a new system image, looks for one on the root of partition four (a.k.a: visible USB storage - when it is exported).
Code:
Charge: 91% [######################################################::::]
update-payload.dat:1 8a21c7f18eb739bb2e348aa34a038f1b imx60_wario/uImage 22 main_kernel
128 e89fe09e72e7bfc948c451f141f51f4a rootfs.img.gz 1618 update_image_rootfs
Finding one, it loads the (new) kernel image:
Code:
imx60_wario/uImage 137330
At this point, the eMMC has the new kernel written to eMMC, but this kernel's modules (on the root filesystem) have not yet been updated.
Next we update the main system image (in partition 1):
Code:
rootfs.img.gz 50399
Then checks the new kernel/initramfs:
Code:
imx60_wario/uImage 137330
Which passes.
Then checks the new system image:
Which fails with a hard, eraseblock error on the eMMC:
Code:
[#:::::::::::::::::::::::::::::::::::::][ 74.190221] mmcblk0: error -110 transferring data, sector 66216, nr 264, cmd response 0x900, card status 0xd00
And your Kindle is toast for several reasons.
But may be recoverable even from this hard, hardware error and mis-matched kernel / kernel modules.
- - - - -
This is already a very long post (for educational purposes of our lurking audience).
And it is late at night here.
So I will follow up tomorrow when mind is still fresh on the things we will try to recover from this.
PS: Remove your current attachment, and using a text editor, XXX out at least your serial number and board id before re-p0sting it.
The reason is that somebody might try to hijack that unique information.
Leading to both your and the hijacker's Kindles being blacklisted.
(Note that I did not quote that information in the above.)