Questions about coresight-tools

[vncntrnst]

Hi there,

I have some questions about the coresight-tools:

1. What do the terms

• locked (csscan output)
• disabled (csscan output)
• hidden (cs_topology output)
• unconnected (cs_topology_dot output)
  mean in this context? I came across these when using the tools.

2. In the csinfo output, it says "ETM system register interface not implemented". What does this mean?
3. In csls, the output does not list any CoreSight devices. It only outputs "** csaccess: ERROR: not a CoreSight component at ..." for some addresses within my devices' ROM tables, but seems to skip (most of) the CoreSight components. Could this have something to do with incorrect devicetree configurations? Or do kernel and DTS configurations not influence the coresight-tools' outputs?
4. In cs_topology, there is no output after "CPU:". Is this normal?

Any help and explanations are very appreciated! I can also provide the complete outputs if you want.

Kind regards,
Vincent

[algrant-arm]

"locked" refers to the locking feature that some CoreSight components implement (writing 0xC5ACCE5 to a lock register), which stops accidental programming. Components that don't implement it, should show up as "no-lock".

"disabled" is going to be showing whatever's relevant for a specific device. So for an ETM it shows whether the ETM is enabled and potentially generating trace. For some components it doesn't make sense.

"hidden" in topology means that we see multiple ATB outputs funnelling into a single input, or a single output replicated to several input, without seeing the actual funnel or replicator component. So we can infer there must be one (or several) but they either don't have a programming interface at all, or it's not visible in the ROM table. A common case is CPU clusters where there's a non-programmable funnel.

"unconnected" means we've detected a trace component in the ROM table, but we haven't detected its connections with anything else.

Some CPUs implement a system register (CP15, MRS/MSR) interface to ETM, as an alternative to the memory-mapped interface. The system register interface allows a CPU to program its own ETM using MSR. On v9, all CPUs can program their own ETEs using MSR, but on v8 and earlier, it's optional. csinfo is reporting whether this particular CPU implements the system register interface.

csls: I don't know. csls is basically a ROM table scanner like csscan.py, but written in C and less fully featured. Looking at the source, it's barely more than a demo. So it won't be relying on Device Tree. It may just be out of date. I'd suggest you first check that the output of csscan.py is what you expect, and then if csls disagrees with that, see if you can narrow it down to a specific component. If it pointed to a bug in CSAL we'd hopefully fix that, but I don't expect we'd make csls give as detailed output as csscan, especially when it comes to reporting the current programmed (writeable) status of devices.

cs_topology no output after "CPUs": if you run cs_topology with no arguments then it runs a self-test and this is the last line. We should improve that. If you're seeing it when you give it an actual JSON file, then somehow no CPUs appeared in the JSON, because they weren't found when csscan scanned the ROM table.

[vncntrnst]

Thanks a lot for the explanations.

I figured out that running csls with the verbose option shows all the detected devices as expected. The errors came from reserved addresses in the ROM tables.

I encountered a few small bugs and some weird stuff when running the coresight tools on my hardware. If you are interested in fixing these, I can give you more details. If not, that's fine, as I got enough information and will now focus on getting the demos running on my boards.

[algrant-arm]

Thanks - definitely interested in fixing bugs although I can't promise anything. It's difficult to test these tools exhaustively given the limited number of CoreSight-accessible targets that we have. We would prioritise csscan.py (and the topology-detection scripts), and the basic device management in CSAL. We do want to keep up to date with CoreSight device types, architecture codes in DEVARCH and so on. csscan.py at least, is regularly run against current silicon (when CoreSight can be made to appear in the memory map), and we want it to be robust and complete.

The demo code and board-configuration code (the one that knows about Versatile Express and not much else) probably isn't going to get a lot of attention any time soon.

When scanning ROM tables there is always a risk of encountering unexpected entries, even getting bus lockups due to powered-down components, security mechanisms etc. It is difficult to entirely defend against these.

[vncntrnst]

Should I share the bugs here, or should I open separate issues for them?

[algrant-arm]

Depends how closely related they are. Having separate issues means we can work on fixes and close them out, but too many issues and it's too much work. If there are issues around device recognition (e.g. adding support for new product codes or vendor-specific codes) I'd suggest one issue for that. And then for any bugs/cleanups in existing functionality, maybe raise one for CSAL C library and one for the Python scripts. But we're not following a strict process!

[vncntrnst]

The bugs I encountered are in the python scripts (I haven't used the C library yet), so I will open a single issue for them.

Another thing: Have you used the python scripts (or CoreSight in general) on a Raspberry Pi?
For my RPi 4B, I wasn't able to find information regarding CoreSight support, and csscan doesn't show any CS devices (besides CTIs), only debug units and PMUs. This is a bit surprising to me, as the Cortex-A72s on the SoC should come with ETMs.

[algrant-arm]

Thanks for creating the issue.

I've tried the scripts several models of Raspberry Pi but never succeeded in detecting or enabling ETM trace. I remember one of them locking up when scanning the ROM table. On Raspberry Pi 5 (with Cortex-A76), I never even found the ROM table address. I haven't seen any public information from Raspberry Pi. There is some public information on external JTAG access but nothing about self-hosted.

I'd expect the CPUs to have ETMs (architecturally, trace is optional, but it's almost always there). But it may be that the downstream ATB components are not present, or are present but inaccessible from the CPUs.

[vncntrnst]

I've tried the scripts several models of Raspberry Pi but never succeeded in detecting or enabling ETM trace.

So I guess it's not even worth trying for me.

I remember one of them locking up when scanning the ROM table.

My 4B sometimes froze when running csscan with some options. But you already seem to know the problems with Raspberry Pis, so I kept them out of #25.

I haven't seen any public information from Raspberry Pi. There is some public information on external JTAG access but nothing about self-hosted.

Yes, this is what I thought. Very unfortunate.