K5 FW 5.3.7.3 ignores ENABLE_DIAGS!

[geekmaster]

I updated the firmware to the latest version (5.3.7.3) on a K5 (Touch), and now it boots to main even when there is an ENABLE_DIAGS file. That rather complicates things a bit. Jailbreak survived the update, and MKK and KUAL work fine after reinstalling them.

Sadly, MfgTool does not work on my current Win7 x64 box (though freescale/nxp has a new version that supports i/MX6), so I cannot boot to diags that way. I will need to add a DIAGS extension for KUAL, that sets the idme boot mode var and does an orderly reboot.

[knc1]

Try RP (Rescue Pack) - it adds ssh to diags and re-enables the recognition of ENABLE_DIAGS.

I am not sure if it is suppose to work on a K5, but check it out.
There is also an extra add-on to RP - the Cowards Rescue Pack.
It will trigger entry into Diags if you leave the cable connected when you re-boot.

[geekmaster]

SSH was in diags (from kubrick). I was not aware of ENABLE_DIAGS needing rescue pack. I have not been following these forums for some time (until recently). I have been reading old threads lately (relevant to things I am interested in lately). Thanks for the pointer... Rescue pack it is...

[knc1]

Your welcome.
I have been on the "help desk" here nearly every day.
A lot of these answers I have memorized.

[NiLuJe]

While the RP itself works perfectly well on a K5, the *CRP* detection doesn't "take" during boot, for some mysterious reason I never really bothered to look into since those can be put into USB downloader mode anyway .

Triggering the CRP job after boot works, on the other hand, so, meh.

[geekmaster]

If I get my hands on newer devices that I can risk by opening and poking and prodding, I plan to find a testpoint or via (or more likely a resistor) that connects to the "magic pin" that enables USB downloader mode. It has to go to one of the pins that sets the boot mode (which need to be tied to resistors, and perhaps some sort of electrical switching mechanism). They must be routed to resistors, which must be on a top or bottom layer (at least according to my understanding about how these i.MX SoC devices work.

We just need to figure out which side of which resistor to short to ground without releasing the magic smoke, and we can adapt Kubrick to these new devices too...

[NiLuJe]

Don't some of those ship with a nice "USB Mode" label near some pins somewhere on the board?

[geekmaster]

Originally Posted by NiLuJe

Don't some of those ship with a nice "USB Mode" label near some pins somewhere on the board?

It seems that for the i.MX6, the boot mode pins do NOT need to be routed:

Originally Posted by Hardware Development Guide for i.MX 6SoloX Application Processors

For BOOT_MODE1 and BOOT_MODE0, use one of the following options to achieve logic 0:
• Tie to GND through any size external resistor.
• Tie directly to GND.
• Float.

For logic 1, use one of the following:
• Tie directly to the VDD_SNVS_IN rail.
• Tie to the VDD_SNVS_IN rail through an external resistor 10 kΩ. A value of 4.7 kΩ is preferred in high-noise environments.

If switch control is desired, no external pulldown resistors are necessary. Simply connect SPST switches directly to the VDD_SNVS_IN rail. If desired, a 4.7 kΩ to 10 kΩ series resistor can be used when current drain is critical.

Boot inputs BOOT_MODE1 and BOOT_MODE0 each have on-chip pulldown devices with a nominal value of 100 kΩ, a projected minimum of 60 kΩ, and a projected maximum of 140 kΩ.

Be aware that when these are logic high, current is drawn from the VDD_SNVS supply. In production, when on-chip fuses determine the boot configuration, both boot mode inputs can be no connects.

Bummer...

[knc1]

Originally Posted by NiLuJe

Don't some of those ship with a nice "USB Mode" label near some pins somewhere on the board?

Yes, all i.MX6 (except Oasis) have clearly labeled switch pad locations (less the switch).

I have pictures, PW2, PW3, KT2 posted somewhere (in my PW3 and/or KT2 treads).

Those are the ones that I hadn't tried, the ones I was going to control with the control outputs of the Jim.fx adapter board.

Now with the info GM quoted, it should be a piece of cake to test it they are working in consumer boards (the other pad outlines work as labeled).

[geekmaster]

Originally Posted by knc1

Yes, all i.MX6 (except Oasis) have clearly labeled switch pad locations (less the switch).

I have pictures, PW2, PW3, KT2 posted somewhere (in my PW3 and/or KT2 treads).

Those are the ones that I hadn't tried, the ones I was going to control with the control outputs of the Jim.fx adapter board.

Now with the info GM quoted, it should be a piece of cake to test it they are working in consumer boards (the other pad outlines work as labeled).

If you can acquire USB downloader mode using these pads, we MIGHT need an updated u-boot for the newer boards (though my modified u-boot images work fine for K3/K4/K5). I no longer have the source code for my mods, but it should be easy enough to mod and rebuild them like I did before -- my mods simply changed the RAM copy of the idme bootmode var early in the uboot logic).

Unfortunately, users will still need to ground a pad before releasing power, to acquire USB downloader mode -- not for the timid. Perhaps we need to design and publish a simple test jig (per kindle model, and which anyone can build) that presses a wire into the correct location without error when the Kindle (with cover removed) is lowered onto it...

[knc1]

That is a possibility, 'jig' idea.
In the "serial jailbreak for dummys" sticky our links to ways to make the connections without soldering.

One of them, the "rubber pad and pins" method might be a starting point for the jig.

= = = =

You don't have to rebuild the initramfs - it can be modified "in place" by simply appending a gzip'd, cpio archive, that over-writes what you don't want and also adds what you do want to the initramfs.

I started to write it up - and will finish RSN because it is how I am going to make a "rescue kernel" for my bricked K2.
(I made a system image change and forgot completely about updating the md5 system manifest == immediate brick.)

PEBKAC at its worse.

[knc1]

Originally Posted by knc1

Yes, all i.MX6 (except Oasis) have clearly labeled switch pad locations (less the switch).

I have pictures, PW2, PW3, KT2 posted somewhere (in my PW3 and/or KT2 treads).
- - - -

See:
https://www.mobileread.com/forums/sho...30&postcount=1
posts 1, 6, probable others

[geekmaster]

That appending a gzip file to another gzip file is correct, because it is "standard" to make a big gzip by appending multiple smaller gzips. I did that back in the day on a few occasions. So yes, the tail-end gzip should overwrite files on earlier prepended gzips...

That Oasis "teardown" thread had pics that showed LOTS of exposed pads. I wonder if there are serial and bootmode (and perhaps JTAG) pins in that pin grid array.

A test jig should also work for serial port access on all the kindles that have bare pads with no connector. What license do you suggest we use for an "open hardware" test jig design (and perhaps 3D printer STL files)?

[knc1]

And we have only seen one side of the board.
That was two pictures of the same side.