Hello everyone !
i did a jtag scan on the testpoints of a nano G2 (one with the flash removed, the soc is probably making nonsense, but should not matter for jtag) of course i excluded from the scan some problematic pins (clocks, power supplies ...). I also scanned with a nTRST search i found no jtag on the testpoints. so here are my hypotheses : 1) jtag is not routed to the testpoints (most likely) perhaps there is an enabling resistor or something... 2) the board could have been broken due to my intrusions (jtag scanning or flash removal) 3) the jtag perhaps has a deactivation in the soc, whatever, SW or HW .... this will only be confirmed when we will know the pinout of the soc. could be hard to achieve. ....................................... I also had a look in the rom image at the interrupt vector table. it seems all the interrupts are re-mapped by jumps to the same table at the beginning of the internal ram (2200 0000), except the reset vector, which is in relative to current + 0x000 8000 this is rather strange, as we assume that we boot on the internal mask rom. my hypothese about this , for the boot process : 1) the arm resets, mask rom is mapped at 0 (remap=0, BOOT_MODE=0) 2) the rom program copies the flash to the internal ram (256kB?, so only 1/4 of it, so up to 0004 0000) 3) the decryption runs from the rom and deciphers the ram between adresses 0000 8000 and 0004 0000 (this is why the encrypted code stops abrupthly at this adress) 4) the rom jumps to a ram adress, probably 2200 8000 where the code begins 5) the ram program sets remap=0, dmap=1, so the ram is mapped at adress 0 instead of the rom. 6) Now the reset vector is valid, and useful. the ram program can now also put valid interrupt jumps (the actuals are a loop at 2200 00xx !!) ....... it seems to me this is the only scenario where the vector table at 0 in the flash can be useful... ....................................... so what's next to dump the rom? JTAG ? no big hope. a solution could be code injection in the flash: it seems the soc can boot from the flash by putting the BOOT MODE pin to 1. we need to find this pin, probably tied to 0, and put it to 1. then we need to wire a easily reprogrammable memory in the place of the flash then we just put a quick routine in this mem that will read out adresses from 2000 0000 (rom) and to output it in some manner. the easiest output i can imagine is the adresses of the flash (reading an adress outputs this adress on the adress bus.) so we would need to emulate the flash with a fpga, and record the adress access as an output. someone ready to experiment ? Olivier ? sto _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
