Thanks, (I think -
).
The hard one first:
Yup, flash is just a bunch of flip-flops and logic gates.
So is the SoC on the main board and the SoC on the 3G board.
(SoC: System On a Chip)
About 2*10^9 * 8 of them or twice that on other Kindle models.
So there is also quite a bit of structure to the device and management requirements of that structure.
Some boring history (but might have keywords for web-searching):
In the case of the most distant relative of today's flash chips -
(Intel 1702 as I recall)
The entire device was erased at once, by intense UV light.
The device was programed in blocks by a high voltage programming circuit.
(eprom : erasable, programmable, read-only, memory)
The next step was to get rid of that "erase by intense UV light" and its quartz window on the chip carrier.
Enter the eeprom: electrically erasable, programmable, read-only, memory.
All of which was provided by external circuitry.
As storage capacities increased, the external circuitry became more complex and over time was moved onto the same chip.
That includes the management and control sequencing, which was moved into a (rom) programmed micro-controller.
A "special function" computer in its own right.
Also the erase and programming voltage generation was moved on-chip.
But as a crude summary,
the USB flash drive, these on-board flash chips, and even the SSD spinning rust replacements are just EEPROM devices on steroids (on triple steroids in the case of SSD devices).
Same limitations on all variteties over the years:
You can erase them, you can program them, you can read them BUT you
CAN NOT write to them.
Sorry, just can't be done.
So the micro-controller has to "fake" the write operation.
The management of the storage is done in "erase blocks" sized parts of the internal structure. 4,096 bytes * 8 bits + ecc bits + vendor defined bits + price of tea in china.
It is interrupting the "life cycle" of an erase block by dropping the power at the wrong time which puts the device into a non-recoverable state.
I.E:
micro-controller's data says an erase block is erased and ready to be programmed (but the power failed before it could be erased completely).
OR:
micro-controller's data says an erase block has been re-programmed (but the programming power failed during the attempt).
OR:
other, less obvious, sequencing errors.
That micro-controller is fairly complex, and on SSD devices, nearly a full computer in itself.
But there are still limits to what it can detect and correct.
If its database says that block 1603456 has been programmed (or erased), and assigned a readable address (or a "ready" address) -
that is what it has to work with.
The easiest to visualize is an incompletely erased erase block (because of power failure to the erase voltage generator) on the "ready" address list.
So that is the next erase block it will try to program, but you can not program an un-erased, erase block.
The device has been rendered useless.
(the controller on an SSD is a lot "smarter" than that, but you still don't want to disconnect their power while they are sequencing)
Doing an "erase mmc" (a full device erase) may or may not allow the controller to re-cover some of the storage capacity.
Chances are: slim - to - none.
- - - - -
The easy one:
Device and owner specific information is stored on the device, outside of the partitioned areas.
You need to make a copy of that (and write it back) to make the Kindle "work" after a full device erase.
Geekmaster has posted scripts and directions -
probably in the older, manual, de-bricking threads.
The "erase mmc" command will also (after erasing the device) re-write the u-boot area with the copy of u-boot currently running in ram.
According to the comments in the Amazon source code, the failure to save and restore the "device and owner" data is an error in the diags programming, which I think has never been fixed.