Hi all,
We’re looking for some information on the Tegra X1 debug infrastructure. After going over chapter 42 in the
X1 SoC TRM there’s some information that really isn’t clear, mostly because the diagrams are downscaled and
the information present is somewhat lacking around those diagrams.
Can someone at nVidia confirm a few things?
-
The source → funnel port mappings for the funnels (42.2.2 is a little fuzzy, and we can only assume
numbering for “CoreSight Minor” and “Quad Atlas/Apollo” subsystems) -
Any method we can use via AXI-AP to power up the components such as ETM and keep them up (at the moment
they are unclocked/powered down and unresponsive at the best of times due to OS power management) or at
least some status bit we can check to see if they’re unavailable via script? -
Confirmation that if we power up the ETM or set EDPRCR.COREPURQ/CORENPDRQ in the Cortex-A57 debug logic
that the PMC will refrain from actually pulling power from these components (this obviously relies on them
being accessible in the first place).
This is essentially to get a proper configuration working in ARM DS-5, since the autodetection process fails
due to powered down components, and we need to bring up the links to the other components. Kudos, by the way,
on documenting the CTI triggers!
Most important for us is some way of determining the power status of the components’ power domains, or better
yet some mask to prevent them from being truly powered off, without breaking thermal management or subverting
the OS. 42.3.4 in the TRM shows a diagram with each core in it’s own power domain along with the ETM,
upsizers, bridges, and another for the non-CPU components. The APE and it’s PTM and CoreSight Minor all seem
to be independently controlled but there’s an obvious race in detecting power vs. accessing a register via
JTAG, so having them just be on while a debug session is in place in a way that doesn’t interact/counteract
normal OS behaviour is relatively important for an external debugger so as not to disturb normal behaviour of
the kernel or power management (i.e. it should think it got it’s way, but the PMC is letting things live in
favour of the external debugger).
Is it possible to get hold of this information, or where we might find it?