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 =0x143dba290 Idx:82978; ID:16; I_TIMESTAMP : Timestamp.; Updated val = 0x143dbdc28 Idx:83713; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x14565a9ff Idx:87068; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x14568896e Idx:87828; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x146f25d9f Idx:91159; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x146f536ac
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.
Al
On Tue, 19 Feb 2019 at 14:42, Al Grant Al.Grant@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
necessary.
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 Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt. 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.
Thanks, Wojciech