Quote:
Originally Posted by geekmaster
So, now that my paperwhite is on order, which of the "no keys" is the magic key? How do we debrick that sucker? Could it use the orientation sensor as a magic key? I remember trying all orientations on a DXG while searching for a magic key. I did not try headphone insertion though -- perhaps the headphone jack could be the magic key on a DXG. But the paperwhite does not even have that. So perhaps the orientation is the only option in the hunt for its "magic" key (for debricking). I suspect that my PW will need debricking soon after I receive it.  |
Perhaps as much as a month in which to do speculation.
This thread may become more entertaining than a game show.
What do we have to go on?
Two things for sure:
Amazon is a for-profit corporation (annual reports not withstanding);
Brand new machines are expensive, when introducing a new model, it is cost advantageous to use as much "tech" that you already have paid the price for as possible.
So far, photographs and limited descriptive materials that show a machine that looks like it could almost be made out of "in stock" parts.
Speculation #1:
Amazon sticks with Freescale for the Kpw (pronounced as Kpew, codename: K9) -
It might even stay with the i.MX508 - its graphic co-processor can handle higher resolution screens than the "improved" one of the Kpw, but maybe not.
Known:
Freescale has burned into the SoC rom a very low level loader (the iROM code) of all of their i.MX products.
This code runs before any off-SoC hardware is initialized.
I.E: Requires a hardware "trigger" (or gpio / register sensed input). The "magic key" we post about.
The machine has two hardware interfaces to the outside world accessible from the outside -
The power switch ;
The USB socket.
It is also possible that it has a "reset" button that can be reached via a pin hole in the case.
We haven't seen the back of the case, nor really good enough photographs to rule out a pin hole (yet).
It may only have a "reset" button (or jumper pads) that can be reached after the case is opened.
IF the case can be opened.
The "next stop" in the boot process is the software program loader (to date - U-Boot).
U-Boot is a fairly large glop of code - it could initialize any or all of the on-chip and off-chip hardware.
Now maybe the accelerometer comes into play - - -
Shake violantly at just the right stage of U-Boot loading and wallah, some sort of mid-level monitor / loader is triggered.
(OR, you just shake the bath water off of it.)
The "next stop" is to load the Linux kernel (presuming they haven't jump ship for WinCE) - -
At this point, the door is wide open for anything at all.
How about a 2x2 pixel area, co-ordinates determined by serial number, date of manufacture and price of tea in china as the "boot interruption" trigger?
A "Morse code" tap sequence?
Or, just about any kind of external event.
Which includes changes in the file system (U-Boot can be enabled to read **simple** file systems, but rarely is).
The models so far have been fairly consistent about recognizing "ENABLE_DIAGS" on the user storage partition.
Why toss out working code?
Plus - a "wild card" entry in my speculation list:
I have not read much about people investigating what that single port "hole" in the firewall is used for.
Is that a "trigger packet" port (sort of like a "wake on lan" type of trigger)?
I will now turn this thread over to other guesstimates.