Originally Posted by TCCPhreak
(or serial, though I haven't got a converter for RS232@1.7V yet)
As soon as I'm brave enough to open the Kindle and solder to the serial port (very very carefully), I'll watch anything it sends.
I kind of hoped that you'd have used a custom mfgboot-profile before (apart form the "switch bootmode"-ones) and could point me in the right direction for trying out writing my own.
But without fastboot, I'm way down at the "can never be destroyed" USB-HID mode and need to work upward to fastboot. I'm just lost in the mass of cmd-commands for fastboot and none of them seem to work with the kindle.
But without any idea on the magic words for "flash file to kindle" in the xml-file, I'm stuck.
The personal information is only readable by the kernel mode drivers. On the newer kindles (K4 and Touch), they replace all of that with \x00 when you read from /dev/mmcblk0. That is why the idme program READS its idme vars (such as bootmode, serial, etc.) from the /proc files (kernel driver interface files) to read this information. The idme program WRITES these vars directly to /dev/mmcblk0 device though, so some areas of mmcblk0 are WRITE-ONLY to applications. This is why it is a bad idea to write to /dev/mmcblk0 with dd, as suggested in some posts I have read. Because a backup copy has zeroes in the write-only areas, a restore with dd would write zeroes onto your important private idme var data.
I once bricked a K4 when the PCBSN idme var got corrupted (as you can read in my forum posts). I had to modify a custom uboot to hijack idme var reads and replace the values with my own known values. This allowed u-boot to finish booting. On a K4, u-boot needs to know the PCBSN to decide how to initialize the device, and it halts if that is bad. This does not appear to be a problem when using the "smarter" Touch u-boot (even when using it to boot a K4, as my MfgTool custom profiles do).
MfgTool is a big program with a lot of capabilities, designed for Manufactures to flash and test new devices. As I understand it, some things require multiple stages, by sending a running a series of increasingly complicated but capable code blocks to the device. There is much in that system that I have not studied yet.
Regarding the serial port, I have discovered that on the K4 and Touch, the third pin does NOT seem to act as a reliable GND (electrical ground). It works MUCH better to keep the USB cable connected from the kindle to the same host PC that has the USB serial adapter, relying on a "ground loop" connection over the kindle USB cable to supply the serial ground. When connected this way, you can also simplify the "serial port level shifter" circuit that I posted in its own thread. With a USB ground, you can connect a 3.3v or 5v serial adapter TxD directly to the kindle RxD (which has a 1K series protection resistor). Some USB serial adapters will require level shifting to see the low voltage signal on the kindle TxD, but if the serial adapter pulls its RxD line to 3.3v or 5V, you just need a small diode connecting the Kindle TxD to the adapter RxD, such that the diode cathode (end with the stripe painted on it) goes to the kindle. This allows the adapter RxD to float to its supply voltage for a logic 1, and the kindle can pull that RxD down to the voltage drop of the diode (0.7v for silicon) for a logic 0. The only problem is that the kindle internal 1K protection diode becomes part of a voltage divider circuit, increasing the logic 0 voltage seen at that serial adapter if too much current is supplied by the adapter. On my USB adapter, the RxD pin was connected to an LED that got its power from a 1K resistor to supply voltage. I had to change that resistor to about 22K to get the RxD voltage seen from the kindle low enough to work correctly. You can get silicon diodes from the circuit board in a defective CFL (compact fluorescent light).
Did you read the docs supplied with the full MfgTool for the iMX50 from Freescale? Download and read the iMX50 Reference Manual too (or at least the relevant parts). It *is* complicated.
I *was* planning to make large changes to a custom u-boot to read and write mmc for me, converting it into a proxy to allow me to read and modify mmc from a host PC. You may want to explore that path yourself too.
Lately, I have been spending my "free" time (very little available) playing with simple but interesting shell scripts, because I have other extremely complex projects occupying most of my attention, and scripts are a fun and simple diversion that are not overly distracting, unlike working with MfgTool.
Good luck. TTYL. Back to work...