k3flasher, a USB download mode utility

[dpavlin]

Originally Posted by geekmaster

Now... who can find the "magic key" for the DX and DXG? And what is the USB VID/PID for DX/DXG USB Downloader mode?

My attempt at DXG:

I tried holding volume down and volume up, and I seem to get power-cycle every 15 seconds (or 1-2 seconds longer) but no device appear on USB bus.

@geekmaster how did you found that holding volume down brings Kindle 3 in usb loader mode?

To be sure that everything works, I tested K3G which works.

[geekmaster]

Originally Posted by dpavlin

My attempt at DXG:

I tried holding volume down and volume up, and I seem to get power-cycle every 15 seconds (or 1-2 seconds longer) but no device appear on USB bus.

@hwhw how did you found that holding volume down brings Kindle 3 in usb loader mode?

To be sure that everything works, I tested K3G which works.

I discovered the K3 "magic key" by rebooting while holding EACH button, until I found one that enumerated as a "different" USB device. As I recall, I almost gave up before finally realizing that the volume buttons might work, so they were literally the last thing I tried.

I tried both the DX and DXG too, but I did not find it. I think I gave up before trying ALL buttons on both devices, but I tried the obvious ones at least.

I later learned that headphone insertion and removal generate keycodes too (as far as "waitforkey" is concerned), but it seems odd that rebooting with headphones in should boot to USB Downloader mode... It is worth a try though, if somebody wants to try it... Or try all the letter keys?

EDIT: You can speed up the process by leaving the USB cable connected so the power LED is on, then hold the power button (backed off just enough to see the LED at its edge) until the LED turns off, then press the "potential magic key", then release power, then release the tested magic key. Look for a new USB VID/PID detected at the host PC.

EDIT2: It is possible (but unlikely) that we need a combination of keys. It is also possible that the DX or DXG uses an internal connection or jumper to boot to USB Downloader mode, instead of a magic key.

[dpavlin]

Originally Posted by geekmaster

EDIT2: It is possible (but unlikely) that we need a combination of keys. It is also possible that the DX or DXG uses an internal connection or jumper to boot to USB Downloader mode, instead of a magic key.

Sorry for incorrect attribution, and thanks a lot for your efforts.

After reading ATK documentation for board config, it seems that i.MX35 TO2 3-Stack Board needs two sets of switches flipped when turning into download mode.

My assumption is that DXG is i.MX31 3-Stack Board based on Revision from /proc/cpuinfo:

Hardware        : Mario Platform
Revision        : 31020

vs K3G

Hardware        : Amazon MX35 Luigi Board
Revision        : 35020

This would mean that it would have a set of 10 switches of which 5 are for booting. If I only took hi-res pictures of DXG last time I opened it, I wouldn't have to guess about this :-)

[knc1]

There are high res pictures of the DX board on the net, I think I indexed them under DX/Teardown

[dpavlin]

Originally Posted by knc1

There are high res pictures of the DX board on the net, I think I indexed them under DX/Teardown

Best one I could found was http://i.techrepublic.com.com/gallery/449093.jpg

OOH, if my assumption about MX31 is correct ATK documentation doesn't give us much hope:

The MX31 T01 chip does not support connecting the COM
port using a USB UART cable. This is because the UART is
set to use Odd parity with two stop bits, which is not
supported when using the USB UART cable in ROM codes.

Fortunatly, I *do* have bluetooth serial in this Kindle (not a good tradeoff for it's battery life), so I have to try it out :-)

Update: Bluetooth connection, while very useful for wireless access to DXG is useless for boot console and messages because it disconnects on reset.

[knc1]

The K3Flasher utility can have the mx31 support added and that limitation (of the ATK) taken into account.

Freescale has another release of the ATK in the works (to take care of some license issues) - they may also fix this limitation.

- - - -

The one you found may be one of those in the set linked to in the first index entry:
https://wiki.mobileread.com/wiki/DX%2...ndex#Teardowns
Which has a few additional detail images in the image gallery.

I will dig around in my browser history, see if I can find the images I had in mind. It was only last week that I was looking at them (a set of 53 detailed images if I recall correctly).
And I obviously forgot to index them once I found them, my bad.

[geekmaster]

Originally Posted by dpavlin

Best one I could found was http://i.techrepublic.com.com/gallery/449093.jpg

OOH, if my assumption about MX31 is correct ATK documentation doesn't give us much hope:

The MX31 T01 chip does not support connecting the COM
port using a USB UART cable. This is because the UART is
set to use Odd parity with two stop bits, which is not
supported when using the USB UART cable in ROM codes.

Fortunatly, I *do* have bluetooth serial in this Kindle (not a good tradeoff for it's battery life), so I have to try it out :-)

Update: Bluetooth connection, while very useful for wireless access to DXG is useless for boot console and messages because it disconnects on reset.

If you use a custom uboot image (similar to how MfgTool is used for K4/K5 select boot), it should be able to be modified to reprogram the serial port for USB-compatible serial parity. Right?

[qlob]

I'm getting an error, could just be my Kindle though...

[root@frankenboxen k3flasher]# sudo ./k3-backup.sh 
This will backup your K3.
After starting this, bring your K3 into USB downloader mode.
The whole backup procedure will take about 1 hour.
W: cannot find device (is it in USB loader mode? are you root?) - waiting for it....................
I: success.
I: found suitable device
E: wrong transfer length, wanted to receive 8 bytes but received 4 bytes.
I: above error can be ignored, it's due to the device being in ROM kernel mode
I: RAM kernel should be running now. Trying to re-open device: .
I: got it.
I: read info
E: wrong transfer length, wanted to receive 8 bytes but received 4 bytes.
E: aborting. It is suggested you power-cycle the device.

[knc1]

Originally Posted by qlob

I'm getting an error, could just be my Kindle though...

[root@frankenboxen k3flasher]# sudo ./k3-backup.sh 
This will backup your K3.
After starting this, bring your K3 into USB downloader mode.
The whole backup procedure will take about 1 hour.
W: cannot find device (is it in USB loader mode? are you root?) - waiting for it....................
I: success.
I: found suitable device
E: wrong transfer length, wanted to receive 8 bytes but received 4 bytes.
I: above error can be ignored, it's due to the device being in ROM kernel mode
I: RAM kernel should be running now. Trying to re-open device: .
I: got it.
I: read info
E: wrong transfer length, wanted to receive 8 bytes but received 4 bytes.
E: aborting. It is suggested you power-cycle the device.

Hmm...
That should indicate that the iROM kernel was unable to load the "RAM kernel" into ram.
Perhaps because it could not start the DDR2 ram.

Try the other "RAM kernel" -
Hawhill is about 8 time zones away, probably asleep at this time, so we have to struggle along without him.

[geekmaster]

That script worked for me. I do not remember where I downloaded the RAM kernel, but I do have a copy if you need it.

UPDATE: After installing ATK, the RAM kernel was here:
C:\Program Files\freescale\AdvancedToolKit-STD\image\mx35to2_mmc.bin

[qlob]

Originally Posted by knc1

Hmm...
That should indicate that the iROM kernel was unable to load the "RAM kernel" into ram.
Perhaps because it could not start the DDR2 ram.

Try the other "RAM kernel" -
Hawhill is about 8 time zones away, probably asleep at this time, so we have to struggle along without him.

Hrm......
Got it to work now, but this could be a bad sign:

[root@frankenboxen k3flasher]# sudo ./k3flasher mx35to2_mmc.bin info
I: found suitable device
E: wrong transfer length, wanted to receive 8 bytes but received 4 bytes.
I: above error can be ignored, it's due to the device being in ROM kernel mode
I: RAM kernel should be running now. Trying to re-open device: .
I: got it.
I: read info
<long pause>
E: reading data from device: LIBUSB_ERROR_NO_DEVICE
E: aborting. It is suggested you power-cycle the device.

[knc1]

Great - the eDDR ram is running now and the "RAM kernel" was loaded and started.

But now it looks like something else failed, under the same conditions where Hawhill said he was starting to investigate the problem.

There is a hardware watchdog that has to be serviced by the "RAM kernel" and this is starting to look as if it is not being serviced in time to prevent it from re-setting the SoC.

We really need to wait at this point for a post by Hawhill since he is working on this exact situation.

[geekmaster]

Does the ATK utility manage the watchdog timer? Can that method be used to recover this borked K3?

[knc1]

Originally Posted by geekmaster

Does the ATK utility manage the watchdog timer? Can that method be used to recover this borked K3?

It is hard coded in the "RAM kernel" and qlob is using the ATK-v1.70 "RAM kernel".

But there are some setup values poked into register locations, and I am not sure if some of those might not change the watchdog time period.

There is a pair of conditions mentioned in the documentation that might be in conflict - -

* The watchdog timer is described as if it is a clock cycle counter (not a time base period). Freescale does not say that, but the relationship between the timer period in seconds varies with the clock speed used by the various SoC chips and I am guessing it is a counter.

* For programming eMMC, the "RAM kernel" is using the bit-serial port **AND** setting the SoC clock speed to that of the eMMC clock speed to simplify synchronous transfers.

? ? A watchdog cycle counter that runs from a changing speed clock ? ?
Now how fragile can that be.

- - - -

One thing that can be tried right away - if qlob is willing ...
Load the **other** eMMC "RAM kernel" (I put both on his /Kloud).

Another thing, for which my drugged up mind is not up to at the moment - - -
Re-build the "RAM kernel" with modified watchdog settings if it is, indeed, hard coded in the code.

The "client" programs (RAM kernels) are cygwin, linux, build system. It should be possible to do that part of the build on Linux with the "bare metal" cross-compiler.

Maybe someone here with build experience can look into that - my mind is not up to it now.

[qlob]

Originally Posted by knc1

It is hard coded in the "RAM kernel" and qlob is using the ATK-v1.70 "RAM kernel".
But there are some setup values poked into register locations, and I am not sure if some of those might not change the watchdog time period.
There is a pair of conditions mentioned in the documentation that might be in conflict - -
* The watchdog timer is described as if it is a clock cycle counter (not a time base period). Freescale does not say that, but the relationship between the timer period in seconds varies with the clock speed used by the various SoC chips and I am guessing it is a counter.
* For programming eMMC, the "RAM kernel" is using the bit-serial port **AND** setting the SoC clock speed to that of the eMMC clock speed to simplify synchronous transfers.
? ? A watchdog cycle counter that runs from a changing speed clock ? ?
Now how fragile can that be.
- - - -
One thing that can be tried right away - if qlob is willing ...
Load the **other** eMMC "RAM kernel" (I put both on his /Kloud).
Another thing, for which my drugged up mind is not up to at the moment - - -
Re-build the "RAM kernel" with modified watchdog settings if it is, indeed, hard coded in the code.
The "client" programs (RAM kernels) are cygwin, linux, build system. It should be possible to do that part of the build on Linux with the "bare metal" cross-compiler.
Maybe someone here with build experience can look into that - my mind is not up to it now.

Now would probably be a good time to mention that I deleted the other kernel because I thought we didn't need it... whoops....