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.