Timestamps always 0x0 on Xilinx Zynq Ultrascale+
Al.Grant at arm.com
Wed Feb 20 17:57:11 UTC 2019
> First, thank you Al for your suggestion to examine TSGEN memory. That was the
> right path. The EN bit of the CNTCR register was indeed 0 and setting it to 1
> enabled timestamps:
> Idx:82685; ID:16; I_TIMESTAMP : Timestamp.; Updated val =
> Idx:82978; ID:16; I_TIMESTAMP : Timestamp.; Updated val =
> Idx:83713; ID:10; I_TIMESTAMP : Timestamp.; Updated val =
> Idx:87068; ID:10; I_TIMESTAMP : Timestamp.; Updated val =
> Idx:87828; ID:10; I_TIMESTAMP : Timestamp.; Updated val =
> Idx:91159; ID:10; I_TIMESTAMP : Timestamp.; Updated val =
> For now, I configured U-Boot to do 'mw fe900000 1' before each boot, so I
> don't have to do it via 'busybox devmem' from Linux - the latter solution requires
> kernel built with DEVMEM=y and STRICT_DEVMEM=n.
Thanks for following up. It's really useful to have that feedback.
It would be interesting to know if the timestamp is correlated with
the kernel timestamp. It occurred to me that just starting and
stopping TSGEN dynamically, might not be a good idea, if the
timestamp actually stops - if that was the case, then to get a
trace timestamp that could be correlated with the continuously
running system timestamp used by the kernel, we'd need to think
a bit more about how we set up TSGEN.
Enabling the trace timestamp at boot and leaving it enabled is fine,
as it at least ensures both timestamps are running all the time.
For production devices where we care about having no power
impact from trace except when actually tracing, we still need to
think about enabling the timestamp dynamically.
> On Tue, 19 Feb 2019 at 14:42, Al Grant <Al.Grant at arm.com> wrote:
> > > > I see. Actually, if I understand the datasheet correctly,
> > > > timestamp generator should be enabled by default on US+ as well.
> > > > Perhaps it's the firmware who turns it off? I remember a post on
> > > > this mailing list, that a firmware update on Juno fixed a similar
> > > > empty timestamps problem on that platform. Fortunately, Xilinx's forks of
> U-Boot and ATF are public, so I'll inspect them for such operations.
> Update on this: there is no code related to TSGEN in U-Boot and ATF Xilinx forks.
> I guess this hardware block is just disabled by default.
> > > >
> > > > If that's the case, do you think it would be beneficial to add
> > > > separate bindings for TSGEN? Perhaps just another reg pair and
> > > > reg-name value to ETM node, similarly to what's already done for stimulus
> base in STM.
> > > > ETM driver could look for reg-name 'timestamp', get the
> > > > corresponding pair from reg, check if TSGEN is disabled and enable it if
> > > > If I understand correctly, that part should be generic, as TSGEN
> > > > is a standard CS component. It's just a random idea, but I'd appreciate your
> comment on that.
> > >
> > > It would be useful to have both.
> > >
> > > Where the chip is managed by vendor firmware and the timestamp
> > > generator is shared with a system control processor (which in
> > > TrustZone terms is Secure) then the timestamp generator really does
> > > need to be directly controlled by the firmware. In that case we need
> > > an API (e.g. via the SMC API) to ask for self-hosted debug be to be enabled.
> > > That could do any number of things - turn on the power domain, turn
> > > off firewalling of debug logic etc. We were trying to get that into
> > > the SMC API - I will chase up where that has got to.
> > Right, there is a number of things to consider here hence suggesting
> > to use the clock framework for this. That way a clock_get/put() would
> > do all the things we want without smearing the CS subsystem.
> I checked that and found an interesting thing. Ultrascale+ (a.k.a zynqmp) has
> firmware and clock drivers in drivers/firmware/xilinx and
> drivers/clk/zynqmp/clkc.c. However, these drivers bind to nothing. There is no
> node with xlnx,zynqmp-firmware compatible in zynqmp DTS files and clock
> nodes use fixed-clock compatible only instead of xlnx,zynqmp-clk. These
> bindings are even documented in
> This looks like some unfinished work.
> Nevertheless, these two drivers look pretty decent. It might be worth checking if
> they work with current Xilinx firmware release. I do not see any CoreSight/debug
> related things in the SMC API exposed by ATF though, so direct memory access is
> the only option to enable TSGEN on this platform, at least at the moment.
More information about the CoreSight