View Single Post
Old 02-04-2020, 04:22 PM   #6
Junket
Nil adsuetudine maius
Junket ought to be getting tired of karma fortunes by now.Junket ought to be getting tired of karma fortunes by now.Junket ought to be getting tired of karma fortunes by now.Junket ought to be getting tired of karma fortunes by now.Junket ought to be getting tired of karma fortunes by now.Junket ought to be getting tired of karma fortunes by now.Junket ought to be getting tired of karma fortunes by now.Junket ought to be getting tired of karma fortunes by now.Junket ought to be getting tired of karma fortunes by now.Junket ought to be getting tired of karma fortunes by now.Junket ought to be getting tired of karma fortunes by now.
 
Junket's Avatar
 
Posts: 278
Karma: 400000
Join Date: Nov 2019
Location: US
Device: PW4
Interesting. I had specifically looked in NXP's documentation for a method to enable USB downloading as this is a key step in programming the full android (phone) address space and presumably android Kindle as well.

NXP's manufacturing tool manual states that the eMMC may be programmed to recover (debrick) an end-user device. Which suggests that there may not be a hardware mechanism (fuse) to permanently disable post-manufacture access or at least that such is not universally employed. But the initialization requirements to write the address space are notably absent. That information may be detailed in the elusive Security Reference Manual that NXP keeps close to their chest.



Manufacturing tool

Alternately, JTAG is pretty much the standard method to read/write the entire firmware address space. NXP's documentation says that "secure-JTAG" can be protected with a key to prevent access to an operating processor. But does not seem to say that standard JTAG access i.e. to a halted processor can be disabled. And in some support of this, I have yet to see a consumer product e.g. satellite receiver, tivo, TV, laptop, ham radio where the eeprom, flash or eMMC couldn't be written after you either removed board power from the device and powered the flash directly or halted the processor.

The following is somewhat i.MX6-centric but likely applies to their other processors as well. NXP has stated that that their JTAG design is "standard" and the majority of JTAG interfaces should be suitable for i.MX6 processors. NXP customers have reported that they can establish a JTAG connection though USB, at least for the i.MX6 development boards with a low cost ($60) Seger J-Link EDU JTAG which communicate with the i.MX6 and properly identifies the architecture. Note that JTAG_MOD=0 must be set (pin grounded) to allow JTAG to halt the processor. Presumably JTAG access would also be available through the SWD protocol.

One possible approach to writing the full address space with JTAG would be to halt the processor, initialize ram and write u-boot to RAM to bypass the locked bootloader. Then use the flash programming features of our u-boot to write the full address space. Here is a working i.MX6 initialization script that does approximately that. This particular script was written for the BDI3000 JTAG, Sabre development board and initializes the DDR ram on the development board rather than the target ram.


Misc. resources:

AN4553: Using Open Source Debugging Tools for Linux on i.MX Processors

S32-DP: S32 Debug Probe ($500) has full processor and memory space access and control on development boards. Debug access is likely disabled on end-user devices though.

JTAG probes for i.MX6 (RealView ICE and DSTREAM)

An overview of 3rd party development tools for ARM
The uLInk Pro debugger ($1,250) is one debugger said to support the A9.


Junket is offline   Reply With Quote