> > 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.