There may be a timestamp generator shared with Secure parts of the chip, so we might be seeing any attempt to read it from Non-Secure treated as a system level error. Not sure why we'd ever need two timestamp generators though. Is this just an ordinary single-socket HiKey960?
Here does single-socket mean single cluster?
No, a multi-cluster system would still typically only have one timestamp generator. Or if it had two, it might have e.g. one for Non-Secure and one for Secure (e.g. for tracing the Cortex-M processors that do all the boot and management stuff we don't see), or maybe one for trace and one for the global time as seen by Linux. At any rate we would not expect timestamp generators to be repeated per cluster of application cores - they are global by nature.
For a physically multi-die system (multi-socket, or these days, multi-chiplet) you would expect one set of everything per die, including timestamp generators per die. This would be in server class systems (almost certainly using ACPI rather than DTS). On such a system the global memory map might have separate ranges for the components for each die, and we would expect timestamp generators in there along with everything else. The system should appear as if it had a single root ROM table that directly or indirectly represented the whole system. We are only just starting to get into self-hosted trace on such systems but we do need to think about it. E.g. it is unlikely trace will be sent between dies, so there will be (at least) one trace sink per die.
Hikey960 have two clusters: CA53x4 and CA73x4 CPUs; And I saw two timestamp blocks:
@0xec037000 0x23b 0x101 r1.0 CoreSight timestamp generator @0xec038000 0x23b 0x101 r1.0 CoreSight timestamp generator
The aborts happen for the second timestamp block.
Ok, that might indicate it's reserved for Secure use. Or it might mean something else... hopefully it's possible to work around by excluding that address.
I don't believe there is any way, in general, of doing a self-hosted discovery via ROM table, that does not carry the risk of having to repeatedly deal with lockups and resets, and add addresses to be explicitly excluded.
What I could do, is automate this in csscan.py - i.e. maintain a continual snapshot of what we're trying to access, and if you run it again after a crash it would spot what you were trying to access and automatically exclude it.
Al
Thanks, Leo Yan
I had thought that was one of the systems we had established we could deal with.
Al
So I use below command to exclude these two registers accessing and then the csscan.py script can finish traversing for CoreSight topology. The great thing is I also can see the script will dump the CTI related registers.
python csscan.py -vvv --exclude=0xec040000 --exclude=0xec080000 0xEC000000
Thanks, Leo Yan
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.