I have just uploaded in gerrit a new WIP patch series aimed at
reworking the tracing.
http://openocd.zylin.com/#/q/topic:tpiu
Before going ahead and finalizing this series, I would like to get
your feedback.

The trigger of this activity has been the need to support TPIU on
complex SoC.
Some discussion in http://openocd.zylin.com/5805

Arm documentation defines 'at least' 6 HW blocks with similar
functionality:
1) TPIU part of Cortex-M3 (ARM DDI 0337G)
2) TPIU part of Cortex-M4 (ARM DDI 0439B)
  These are defined as 'optional component' 'designed for low-cost
  debug', 'special version of the CoreSight TPIU'.
  Actually they include functionalities from CoreSight TPIU and
  SWO blocks.

3) CoreSight TPIU (ARM DDI 0314H)
4) CoreSight TPIU SoC-400 (ARM DDI 0480F)
5) CoreSight TPIU-Lite (ARM DDI 0317A)
        These only address the 'sync' mode supported by OpenOCD.

6) CoreSight SWO (ARM DDI 0314H)
        This only addresses 'async' modes NRZ/UART and Manchester.

While 1) and 2) are the common blocks found in simple MCU, they
get replaced by more complex architecture as soon as a second core
gets placed in the same SoC.
STM32H745 and STM32MP15x are my main reference but, as reported by
Adrian Negreanu, there will soon be an NXP i.MX RT1170 (M4+M7)
that follows the same path.

In such a multi-core SoC we lose the concept of TPIU or target X;
we now have the TPIU of the SoC where all the cores are connected.

The blocks TPIU and SWO are not anymore located at default address,
nor necessarily in the same access port used to debug one core.

Due to all the arrangements above, I'm proposing in the series:
- split TPIU and SWO. Thanks to their non-overlapping register
  space the same code can address both.
- make TPIU and SWO independent from the target. Now in the config
  file TPIU and SWO must be created. The trace commands are not
  anymore linked to the target name. The target event
  'trace-config' is replaced by TPIU/SWO event 'post-enable'
- rework the trace command to make it lighter. Use the 'configure'
  method to set all the specific parameters, then commands
  'enable' and 'disable' to do the tracing.

Questions to address:
- is it ok to have 'swo create' and 'tpiu create' that are exactly
  the same command?
- do we need '<target-name> tpiu' commands (that fallback to the
  first TPIU available) My feeling is that it only adds confusion.

What is missing, incomplete, broken, ...:
- documentation not completed
- all the old tracing code has to be removed and replaced by
  'deprecated' wrappers
- remove the documentation of the old tracing command
- more config files has to be modified. I don't want to have a
  default TPIU for each Cortex-M target, because it exists only
  for M3 and M4 and it's even optional
- maybe add other events. 'pre-enable' is welcome with some SoC to
  turn on the trace clock, otherwise openocd hangs while program
  an un-clocked TPIU
- rebase Tarek's proposal http://openocd.zylin.com/5345/ on top of
  this

Other, out of the scope of this series:
- review the definition of target_register_timer_callback() and
  target_call_trace_callbacks(), since they do not need to be
  target related.
- there is a bug in STM32H7 config file. It is badly patched here,
  but a separate check is required.

How to use the new commands.
Example with NUCLEO-H745ZI-Q using the sample FW pre-loaded
by board manufacture; test on both cores:
# openocd -f board/st_nucleo_h745zi.cfg
from telnet interface:
> stm32h7x.swo configure -protocol uart -traceclk 100000000 -pin-freq 100000 
> -output /tmp/test
> stm32h7x.cpu0 itm port 0 on
> stm32h7x.cpu1 itm port 0 on
> stm32h7x.swo enable
> for {set i 0} {$i < 8} {incr i} {stm32h7x.cpu0 mwb 0xE0000000 0x30}
> for {set i 0} {$i < 8} {incr i} {stm32h7x.cpu1 mwb 0xE0000000 0x31}
> stm32h7x.swo disable
then check the result:
$ hexdump -C /tmp/test
00000000  01 30 01 30 01 30 01 30  01 30 01 30 01 30 01 30  |.0.0.0.0.0.0.0.0|
00000010  01 31 01 31 01 31 01 31  01 31 01 31 01 31 01 31  |.1.1.1.1.1.1.1.1|

Antonio


_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to