Quote:
Originally Posted by jprince
- - - -
What was showing on the screen when it 'hung'? It cycled to boot, however, the "active" graphics don't fill the whole screen, rather the upper right. Perhaps as if it doesn't know its dimensions?
When the USB cable was connected, Kindle to PC, could you see the storage on the Kindle? yes, originally, however, after trying DO_FACTORY_RESTORE (and I mean, I did a touch -m /Volumes/Kindle/DO_FACTORY_RESTORE to create the file, it no longer seems to mount. However, the first time after that, it proceeded to ask what language I wanted to use. The graphics were/are still small, but the onscreen hit targets matched as if it were full size. Regardless, hitting Next lead back into boot cycling
- - - -
|
That is clear enough for me to make an educated guess as to what is happening (without a clue yet on how to fix it):
The "Recovery" style packages contain a kernel image with an embedded initramfs (which includes the 'at boot time' screen drivers).
Somehow, the process is running
the wrong combination kernel/initramfs image file.
There probably needs to be a re-boot (maybe to the second kernel/initramfs image) in the process somewhere.
If the above is so - then the looping is probably caused by the update code trying to replace the kernel/initramfs while it is still running from eMMC storage (a programming Oops).
No clue at the moment if the above guess-work is true.
- - - -
And the initramfs code is in violation of the GPLv2 license of the Linux kernel -
It is embedded in the kernel image file (making it GPLv2 also) but Amazon has never released that source code as required by the license.
Note:
There is a way for u-boot to load a kernel and a non-embedded initramfs, added to the kernel code just for the purpose of keeping initramfs code proprietary, only Amazon has never use it.
I even know the person who did that, and why.