FreeCalypso > hg > freecalypso-hwlab
comparison doc/Calypso-OpenOCD-Howto @ 63:66879ce73b3e
doc/Calypso-OpenOCD-Howto article written
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Wed, 26 Jun 2019 23:04:26 +0000 |
parents | |
children | 6d02f30e35ad |
comparison
equal
deleted
inserted
replaced
62:240221552ecf | 63:66879ce73b3e |
---|---|
1 Using OpenOCD to operate on Calypso JTAG: proof of concept | |
2 ========================================================== | |
3 | |
4 We have a proof-of-concept OpenOCD configuration for talking to Calypso JTAG | |
5 based on the theoretical findings described in the Calypso-JTAG-notes document | |
6 in the freecalypso-docs repository; the present document describes how one can | |
7 practically use OpenOCD on an FCDEV3B target. | |
8 | |
9 Choice of JTAG adapter hardware | |
10 =============================== | |
11 | |
12 The PoC presented here uses an off-the-shelf unbuffered FT2232D breakout board | |
13 with a special EEPROM configuration as the JTAG adapter, as described in the | |
14 Unbuffered-FT2232x-JTAG article. ADBUS0 through ADBUS3 are wired to standard | |
15 JTAG signals as required by FTDI and ADBUS7 (acting as a GPIO) is wired to the | |
16 XDS_RESET line on JTAG connector pin 2. This choice of using a generic FT2232D | |
17 breakout board as opposed to a more purpose-made "professional" JTAG adapter | |
18 was made deliberately in order to force the user to make a mental shift | |
19 regarding reset signals: any standard JTAG adapter product will have two reset | |
20 outputs designated as TRST and SRST, but the XDS_RESET signal on the FCDEV3B | |
21 does not correspond to either of those. But a generic (non-JTAG-specific) | |
22 FT2232x breakout board does not have TRST or SRST, it only has ADBUS and ACBUS | |
23 pins that become GPIOs in MPSSE mode, allowing the user to break out of the | |
24 TRST and SRST mentality: you just have a bunch of GPIOs, then arbitrarily pick | |
25 one of those GPIOs and connect it to XDS_RESET, *without* associating it with | |
26 either TRST or SRST. | |
27 | |
28 The full set of needed wire connections is thus: | |
29 | |
30 FT2232D signal FCDEV3B JTAG signal | |
31 ----------------------------------- | |
32 ADBUS0 TCK (pin 11) | |
33 ADBUS1 TDI (pin 3) | |
34 ADBUS2 TDO (pin 7) | |
35 ADBUS3 TMS (pin 1) | |
36 ADBUS7 XDS_RESET (pin 2) | |
37 | |
38 You will also need to connect at least one ground pin, hence 6 wires in total. | |
39 There is no need to connect the undocumented and non-understood EMU0 and EMU1 | |
40 signals - we don't know what to do with them and we work without them. This | |
41 wiring arrangement and all functionality described in this article work exactly | |
42 the same way on both D-Sample and FCDEV3B boards. You will also need to | |
43 reprogram the EEPROM on the FT2232D board as described in the | |
44 Unbuffered-FT2232x-JTAG article *before* you connect it to the Calypso target | |
45 board. | |
46 | |
47 One can also connect just the 4 JTAG wires, without reset: there are some | |
48 historical commercial phones and modems on which JTAG lines are accessible, but | |
49 Iota nTESTRESET is not, or perhaps nTESTRESET is accessible, but you don't feel | |
50 like replicating the transistor circuit that is required in order to drive it | |
51 safely - the circuit that is present on development boards, but not on hacked-up | |
52 phones and modems. In that case you will still be able to halt an already- | |
53 running Calypso, but of course you won't be able to exercise reset_halt or | |
54 reset_run operations described below. | |
55 | |
56 Unpowered FT2232D adapter quirk | |
57 =============================== | |
58 | |
59 If you connect the FT2232D board to the FCDEV3B as described above, including | |
60 the XDS_RESET signal and ground, you will notice the following quirk: if the | |
61 custom-crimped JTAG cable is connected between the two boards, but the FT2232D | |
62 board is not plugged into a USB host (has no USB power), the FCDEV3B will be | |
63 held down in test reset: the green LED will be off, and neither button on the | |
64 board will do anything. The FCDEV3B will be released from this reset and will | |
65 boot in test reset mode with the green LED on the moment you plug the FT2232D | |
66 board into your USB host. | |
67 | |
68 Running OpenOCD | |
69 =============== | |
70 | |
71 With the FT2232D board plugged into your host PC or laptop and programmed with | |
72 the custom USB ID of 0403:7151, you can run OpenOCD with the custom config file | |
73 presented in the calypso-jtag directory in this repository: | |
74 | |
75 openocd -f ft2232d-unbuf-poc.cfg | |
76 | |
77 Being a proof of concept, this OpenOCD config file does not follow any of the | |
78 guidelines regarding separation between adapters and targets, but is fully | |
79 monolithic instead. This config is written to work with openocd-0.10.0 | |
80 (depends on the new ftdi driver), but does NOT use the target/ti_calypso.cfg | |
81 fragment that has been included in mainline OpenOCD for quite some time: in the | |
82 Mother's opinion, the latter is bogus. If someone wishes to bring Calypso | |
83 support in the mainline OpenOCD distribution up to par, I do not have any | |
84 advice or guidance for you: it is your job, not mine. The present PoC config | |
85 that is rather antagonistic to mainline OpenOCD, its framework and its | |
86 guidelines will always remain our standard answer to FreeCalypso customers | |
87 asking how to make JTAG work. | |
88 | |
89 When you run OpenOCD as above, the FCDEV3B target needs to be in the running | |
90 state with the green LED on. OpenOCD will exercise and verify the scan chain, | |
91 but it won't issue any resets or halts on its own, thus whatever code was | |
92 running on the board won't be disturbed in any way by the act of running | |
93 OpenOCD. You can then reset and/or halt the target as desired with our custom | |
94 commands (Tcl procedures) as described below. | |
95 | |
96 Halting the Calypso without a reset | |
97 =================================== | |
98 | |
99 To halt an already-running Calypso ARM7 core without a reset, stopping it at | |
100 whatever point it happens to be in its code execution, execute this sequence: | |
101 | |
102 enable_halt; halt | |
103 | |
104 The enable_halt step is a custom Tcl procedure added by us, issuing the | |
105 mysterious 0xB instruction and DR scan that are needed in order to enable halts | |
106 on TI's modified version of the ARM7TDMI core. Once you have halted as above, | |
107 you can resume and halt again without needing to re-execute the enable_halt | |
108 step; the only time when the enable_halt steps will need to be repeated is when | |
109 the Calypso is reset. | |
110 | |
111 You can safely halt the Calypso in this manner when the flash is blank and the | |
112 boot ROM waits forever for a serial download, when you have loaded a RAM image | |
113 with fc-xram -j and the target is left in loadagent, or when one of our standard | |
114 firmwares is running; in all of these states the Calypso watchdog timer is | |
115 disabled. However, if you are going to halt the Calypso when the watchdog timer | |
116 is running, you will need to execute our wd (watchdog disable) command quickly | |
117 after the halt, before the watchdog timer is allowed to expire. A simple way | |
118 would be: | |
119 | |
120 enable_halt; halt; wd | |
121 | |
122 The wd command (Tcl procedure) name was deliberately made short so it can be | |
123 typed quickly with fingers if need be. | |
124 | |
125 Resetting with or without a halt | |
126 ================================ | |
127 | |
128 We don't support OpenOCD's standard reset command because we found it too | |
129 difficult to override its built-in assumptions which are wrong for our Calypso. | |
130 Instead we have our own reset_halt and reset_run custom commands (Tcl | |
131 procedures) that replace OpenOCD's standard 'reset halt' and 'reset run', | |
132 respectively. | |
133 | |
134 The reset_run command will reset the board without halting the Calypso, letting | |
135 it boot and run normally. It is equivalent to pressing the RESET button on the | |
136 board with your finger, except that it also re-initializes OpenOCD's scan scain | |
137 and "target examination" state which would otherwise get confused. | |
138 | |
139 The reset_halt command will reset the board and halt the Calypso immediately as | |
140 it comes out of reset, halting at the reset vector before the first instruction | |
141 of the boot ROM code (or the first instruction from external memory if operating | |
142 on a D-Sample board with the boot switch set to external) is executed. The | |
143 necessary disabling of the watchdog timer (wd procedure call) is already built | |
144 into the reset_halt Tcl procedure; except for this wd step, all Calypso and Iota | |
145 registers will be in their most pristine reset state. | |
146 | |
147 Recovering bricked Compal phones | |
148 ================================ | |
149 | |
150 Some Mot C1xx phones have Calypso JTAG signals brought out to accessible contact | |
151 pads, allowing a way to recover from a bricked flash bootloader via JTAG. | |
152 However, they do not bring out Iota nTESTRESET, instead they bring out a signal | |
153 which they call DLPWR, which is really Iota RPWON. A procedure similar to our | |
154 reset_halt would need to be performed as the first step in the recovery | |
155 sequence, but it would need to be modified to work with DLPWR instead of | |
156 XDS_RESET. The RPWON aka DLPWR signal will need to be driven with an OC/OD | |
157 driver (it is internally pulled up to raw VBAT, which is not a safe voltage for | |
158 standard 3.3V logic), and the switch-on and boot sequence will be triggered | |
159 when this signal is pulled low, i.e., transitions from high to low. The | |
160 subsequent release transition (from low back to pull-up high) does not matter, | |
161 i.e., RPWON may be permanently pulled down as the Calypso boots and runs, very | |
162 much unlike nTESTRESET or XDS_RESET. | |
163 | |
164 It will be up to you to design whatever circuit you wish to use to produce an | |
165 OC/OD driver that can be triggered from OpenOCD, but connecting RPWON aka DLPWR | |
166 directly to an FT2232x I/O pin is not acceptable. Copying the circuit from | |
167 TI/FC development boards that propagates XDS_RESET into nTESTRESET won't work: | |
168 this circuit only works when the V-IO regulator is already on, but RPWON is not | |
169 a reset and will need to be triggered when the chipset is fully "cold". | |
170 | |
171 You will also need to figure out the appropriate timing. You will need to | |
172 insert a certain delay between RPWON assertion and the 'jtag arp_init' step in | |
173 our reset_halt procedure: the VRPC state machine in the Iota chip will do a | |
174 bunch of work between sensing a low on RPWON and releasing the Calypso from | |
175 reset via ON_nOFF, and until then the JTAG scan chain won't work. But the | |
176 delay cannot be too long either, or you won't halt the Calypso before it starts | |
177 executing bogus code from the phone's bricked flash. | |
178 | |
179 Once you do get a working reset_halt variant, the following steps will be | |
180 straightforward: | |
181 | |
182 1) Run fc-loadtool -h compal -c none /dev/ttyXXX on the serial port connected | |
183 to the phone's headset jack; | |
184 | |
185 2) Enable the boot ROM and jump to it with these commands: | |
186 | |
187 mwh 0xFFFFFB10 0x100 | |
188 resume 0 | |
189 | |
190 The boot ROM will run while fc-loadtool is sending its beacons, fc-loadtool | |
191 will load and run loadagent, and you can then recover the flash. |