AM335x Debug Access Port in Linux SDK 7.00.00.00

Moving to Sitara forum.

Best regards,
Miroslav

Phil, I'll try to ask someone from the factory team, who is familiar with the debugss about this and will let you know when I have an answer.

Best regards,
Miroslav

Hi Phil, i was able to recreate your problem on our EVM with SDK 7.0.  It seems this version of the kernel is disabling the DEBUGSS module clock.

I was also able to connect to both the Cortex-A8 and the DAP with the fix you mentioned above (actually, adding just ".flags HWMOD_INIT_NO_IDLE" worked for me).

So i'm not sure why you can't access the DAP.  Are you attempting to connect to the DAP in CodeComposer?  Are you able to connect to the Cortex-A8 in Code Composer?  Can you dump the registers 0x44E00414 and 0x44E00418?

Thanks,

James

Hello James

Thank you for your answer. I can connect to the DAP in CCSv6 and dump the register you mentioned (52500002 0000001A). I can also connect to the Cortex-A8 and debug the kernel. I thought having narrowed down my initial issue to the DAP access – my conclusions were apparently wrong.

I am trying to lunch a Custom System Trace Session (SD 560v2 STM) when linux kernel 3.12 is already running. The gel script is writing to 0x47C3E088 via DAP (AM335x_trace_dapdebugss.gel). The memory at 0x47C3E000 is not accessible via DAP. Unfortunately I can not find any technical reference on the device at 0x47C00000. I assume that in the kernel 3.12 the device is switched off (like the JTAG). When I use the 3.2 kernel I can access to the memory at 0x47C00000 via DAP.

Can you try to lunch a Custom System Trace Session ?

Regards

Phil

Hello James

Thank you for the configuration. I wrote the registers and have access to the L4 Firewall again. The Custom System Trace with the ETB does run now – but not on the v560v2 STM. The pin configuration is still wrong (CCS error: transmitter frequency measured at 0Hz). I guess I have to check the pinmux configuration. I thought the gel file does the pin reconfiguration. Unfortunately I have to postpone the gel file adjustments for a few days (AM335x_trace_dapdebugss.gel)

Regards

Phil

Hello Matthijs

I will have a look at the dm814x. The am335x manual is thick but not even close to be complete. Many sections in the memory map are marked as “Reserved”. I am new to the Sitara CPUs and don't really like blind spots or does the TRM of the TRM's exist ?

Regards

Phil

Phil_CH said:

Hello Matthijs

I will have a look at the dm814x. The am335x manual is thick but not even close to be complete. Many sections in the memory map are marked as “Reserved”. I am new to the Sitara CPUs and don't really like blind spots or does the TRM of the TRM's exist ?

I should note that the dm814x TRM is thick but not even close to being complete. (Yes, there's a pattern there ;-)  Also, these two chips may not seem very related at first sight due to their very different feature set, but for example if you compare the L3/L4 memory maps you'll notice that whenever an address range is in use on both chips, it is in use for the same purpose¹.  This also partially explains the many "Reserved" ranges: while dm814x has a pretty densely packed L4-Per (in fact it uses 128 regions, the max supported afaik), a fair number of those are omitted on am335x and some were moved to L4-Wakeup (which doesn't exist on dm814x).  New peripherals were added, but at non-conflicting addresses.  Many of the (re)moved peripherals were simply marked "reserved" in the memory map, making it look a lot more mysterious than it actually is.

Also, as part of their apparent goal to make the am335x interconnect as poorly documented as possible, they marked nearly all other interconnect-related register blocks as "reserved", in particular the target agents which are the 4 KB "reserved" block following each peripheral on an L4 interconnect.  I posted some more interconnect-related info in this thread.

I share your dislike for "blind spots", but unfortunately TI filters their TRM based on what they think is appropriate for the intended audience and application domain.  I can partially understand it, especially after I came across some irc log where someone lamented how a single mention of some interface resulting in some customer demanding support for it.  Still, it would be nice if the missing docs were made available via an alternate route for those willing to accept being "on their own", like they did with the am335x PRUSS docs.

A pretty decent understanding of a device can nonetheless be obtained over time by keeping one's eyes open and cross-referencing docs on related chips, especially since which info makes it into a TRM varies per device:  dm814x TRM has pretty decent interconnect docs, but no info on debug whatsoever.  dm816x TRM has some actual info on debug and trace, but basically nothing on the interconnect.  (I can also recommend not throwing away old versions of TRMs, info sometimes disappears.)  Having to cross-reference documentation like this is, of course.... not ideal.  But it seems to be the best option available if one desires a more thorough understanding.

On the other hand, TI's public documentation still seems to be far above average in quantity and quality.  For comparison, people working with the raspberry pi have this as "TRM" for that broadcom chip it uses, and the errata are community-maintained on a wiki since no official ones are published.  Suddenly, the complaints I have about TI's documentation seem relatively insignificant ;-)

Speaking of errata and coming back to the original topic of this thread:  I just remembered that the am335x errata list two items which are related to trace, you may want to take a look at those.

¹Unfortunately this doesn't always mean they are compatible:  for example, while they both have a similar Ethernet switch subsystem located at 0x4a100000, the individual register blocks therein are in a different order, some registers were moved around, and even some individual bits moved from one control register to another.  Some hardware designers must really hate driver programmers.