DRA829J: Debug Interface documentation of the DRA829

Hello,

The TRM in this targets describing features not providing information necessary for an implementation.  The information to do that is spread across many other documents (ex ARM coresight debug and arm core documents).   The DRA829 does implement a coresight compliant ROM table which can be scanned to provide the component information.

For generic debug you will find a standard APB-AP on DAPBUS APSEL-1 (for debug component control, with a rom table at apb:0x0) and an AXI-AP (for system bus access) at APSEL-2.   This is accessed via a standard ARM DP.   An ice-pick-m is in parallel but is not needed for debug, it only needed if bsdl is desired (EMU0=1, EMU1=0 as seen in the compliance section of the BSDL file for the CPU).

A number of 3rd party and community JTAG tools already support from Open-OCD, CCS, Seggar, Isystems, GHS, Lauterbach, etc...

We do not have access to AP1 and AP2.

In some forums, there is talk of "Power-AP", "Secure-AP", or "Sysctrl". However, I have not found any description of them. I also have not found any description for the EMU0/1 pins and their significance.

We need an overview/description of the various APs and their registers. Specifically, an initialization sequence that describes which values need to be written to which registers of which APs in which order to ultimately access the entire memory area via an AP.

For example, in OpenOCD, the value 0x00190000 is written to AP3 register 0xF0 or 0x00102098 to AP3 register 0x44. There must be a description somewhere explaining why this is done and what these values mean?

The Power-AP and Secure-AP are not currently part of publicly documented registers.  In example projects their usage is required for handling debug of TI internal firmware which runs on the M3 and for some high security (HS) debug senecios. The documentation around the M3 and security system is only currently available via NDA.

For GP devices the initial state for all cores debug is open.  Use of the APB-AP on APSEL-1 is all that is needed for R5 and A72 cores.  Access to the AXI-AP on APSEL-2 is needed to use the AXI-AP as a memory access port to the system memory space.

The values seen in some examples around APSEL-3 (which you cite) is required as a bug work around on J7ES (however it is not needed for other SOCs in this family, code which may have elsewhere is in error).   This sequence creates a clock request needed to establish a connection on a GP device with the Cortex-M3.  This is useful for TI-firmware development and for some high security use case.   The common scenarios where a person boots firmware then develops on Cortex-R5's+other cores do not require access.

Thanks for your information.

We are able to work with AP1 and AP2 and also could read the Cortex M3 ARM ID at AP7.

Now we encounterd the problem that we can not access the A72 any more. Cause of this is maybe that we deleted the QSPI flash.

Can you help us where we find a detailed boot sequence and if the "not programmed" QSPI memory could be the problem why we can not access the A72 core anymore.

Hello,

With your AP1/AP2/AP7 access working you are enabled to get to the next levels.

At power on reset the A72 domain will be powered off.  It will not be possible to probe into its APB segment till powered and clocked.  You will have access to the M3 and the MCU-R5 as their ROMs will start them up.

To power the system fully to re-enabled debug you would need to port the CCS-GEL files which do a 'jtag-init' of the system or you would need to create a boot image.  The TI SDK has the ability to create images and their will be prebuilt ones.  The most common-fast way to boot would be to program an SD card with a boot image and set the DIP switches for SD boot.  The SDK information can be found here: https://www.ti.com/tool/PROCESSOR-SDK-J721E . 

Hello, 

thank you for the info.

" To power the system fully to re-enabled debug you would need to port the CCS-GEL files which do a 'jtag-init' of the system "

This is what we need! We want to know what commands need to be written to which address and access port.

Where do we find the gel file that is doing that? Or wher can we find the respectiv documentation?

best regards,

ralf

Hello,

Thanks for the answer. Unfortunately, the gel files call functions that I can't find anywhere, e.g.

GEL_EvalOnTarget()
GEL_SetWaitInResetMode()
Turn_On_LPSC_WKUPMCU2MAIN()
Setup(CSL_PLL0_CFG_BASE, address_offset, MAIN_PLL_INDEX, OFC1);
...

Where can these functions be found and where is this initialization documented?

Many thanks and best regards

Frank

Hello,

Your question came at an out of vacation time.  For the above functions, the later functions Turn_on_LPSC... and Setup() are familiar and should be in GELs.  GEL functions make up a global name space and can call once loaded. For example a simple grep shows Turn_On_WKUPMCU2MAIN() is defined in J7VCL_PSC.gel and Setup() is defined in J7VCL_PLL.gel.

Past the installed functions, there are cases where a call to a non-existent function sometimes is in GELs.  Those usually are on paths which the main flows don't ever call.  You did not cite those but I have found time.

The GEL_xyz functions are built-in functions and those will be harder to resolve.  Those need to be looked up in the generic CCS documentation.  The GEL_SetWaitInResetMode() in many cases is not effective on DRA829 as that writes to a shadow register which the firmware does not implement.

Hello,

thanks for the answer. I have found and implemented all the functions (except the GEL_xyz). Unfortunately, the CCS documentation does not describe exactly what these GEL_xyz functions do.

On one board I now have access to the Cortex-A72 and the memory area (RAM, OSPI, ...). But on another board this does not work. There I have no access to the Cortex-M3. It may be a high security (HS) device. Is it possible to find out via debug interface whether it is an HS device?

It says somewhere that a certificate must first be loaded for the HS devices for debugging. Is this process documented anywhere? How is this certificate created? And how and where is it loaded via JTAG?

Thank you very much.

Regards,
Frank

Hello,

From your description the 2nd device is a HS device.   This can be of type HS-FS (field securable) or HS-SE (security enforced).  In functional boot modes JTAG is locked on the M3 core on HS devices.  For other cores the JTAG may or may not be open depending on credentials embedded in the boot image.  The firmware (once loaded) can be sent an unlock cert via JTAG.  The structure of the x509 certs used in in-image-unlock and jtag-injected-unlock are part of the SDK documents: 

https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/sec_cert_format.html#sysfw-debug-ext

https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/runtime_debug.html

https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/sec_ap_data_transfer.html

https://www.ti.com/lit/ug/sprujc1/sprujc1.pdf

Hello,

Thank you for your reply and the links to the documents.

I will implement and test the function of loading the x509 cert via JTAG for unlocking. If I have understood this correctly, the firmware currently running must have been prepared accordingly. Is that correct?

And if it is not? Is there then a "bare-metal ‘non-firmware’ usage" variant? I will probably have to implement this too. Can you please support me in implementing this variant with further information?

Thank you very much.

Regards,
Frank

Hello,

Yes, you are correct the functional boot unlock is handled by the boot image which the SDK generates.  That boot image has a header + certificate + Cortex-M firmware object + Cortex-R5-MCU object.  The mask ROM on the M4 and R5 coordinate image loading based on DIP switches.  After a well formed image is processed the JTAG will be unlocked and you can attach your tools.  Its common for a customer to out a while(1) look at their R5 entry function to server as a clean attach point.   The common usage is this one.  A certificate can keep the cores JTAG locked and the JTAG tools can send down an unlock cert to open it up.  These paths are described in the documents I have sent pointers to and in the SDK examples.

What is your ultimate goal? Generic support for all possible test and debug scenarios is a huge undertaking and would take a huge amount of effort and time.  If your goals is limited there may be a few sub paths which could be described.  If your goal is something like initial boot flashing, recover, and board test, you probably can do everything with BSDL and bypass a lot of SOC internals.

Hello,

Thank you for your reply.
However, this now contradicts my theory. I have deleted the bootflash via boundary scan and still cannot access the CM3. Although no more firmware is running. Are there perhaps other conditions that are blocking the access?

My ultimate goal is to get access to the first Cortex-A72 core, load executable code into RAM and execute it. This is to program an external QSPI flash with data via JTAG. This already works on another DRA829 device. Yes, this is also possible via boundary scan, but this variant is much faster.

Thank you very much.

Regards,
Frank

With the flash image gone, only the Cortex-M3-DMSC and the MCU-R5 will be powered as part of the failed image probe. You will not be able to attach to the Cortex-M in a functional boot mode for a HS devices. For HS-FS on current devices, the MCU-R5-0 will be in a position to JTAG attach to, this can be used to run power up gel files (1st revision devices behavior is more restrictive for HS-FS).   All the other cores are powered down so no access is possible for them until powered.  On an HS-SE device no cores can be connected without an auth.  The ~common SW to debug low level images as found in current SDKs for HS devices creates a 'null SB' which amounts to an minimal image which has cert+firmware+while(1)-loop-on-MCU-R5.  This description lines up with the public documentation shared.

Thank you for your reply. If I have understood this correctly, then I should have access to the M3 without the flash image? Unfortunately this is not the case. 
But the better way should be to load and start via the MCU-R5-0 cert+firmware+while(1)-loop. Is this then possible for all device types? Would it then be possible to power the A72-0 via the MCU-R5-0? Which JTAG Access Port (AP) can I use to access the MCU-R5-0 and load the image? How can this image be created? To which (RAM) address should the image be loaded? Unfortunately, I cannot find this information in the public documentation.

Regards,
Frank

No, you will not have access to the M3 as my message says: "you will not be able to attach to the Cortex-M in a functional boot mode for a HS devices"

No, it is not possible to power the A72 with the JTAG Access Port. The cluster has more complex preconditions than that.  What is done in GEL files or in SBL bootloaders is required.

Yes, you can use the R5 as a way to setup A72 clocks and put an A72 boot image in place.  The SDK code is arranged in one way, if its rearranged other ways are possible.  GELs run from the R5 can also allow for prepping the A72 for running an image.

As already mentioned, I have already successfully powered the A72 on another device via JTAG. However, via the M3 via Acess Port 7. Now I can only do this for the HS devices via the R5.

Which JTAG Access Port (AP) can I use to access the MCU-R5-0 and load the image? How can this image be created? To which (RAM) address should the image be loaded? Unfortunately, I cannot find this information in the public documentation.

Regards,
Frank

Hello,

What you have written is not ~accurate.  At reset even on a GP device it will not be possible to solely jtag attach and power the A72.  I even just made a quick try to check this expectation. From the JTAG AP port there is no 'force' power on which is possible for the A72.  When you attached via JTAG previously some other code or gels on the system would have to have run to clock, power, and setup boot-reset registers for the A72.  Likely you attached on a system which had some code or a init GEL was written.   On an HS-FS as I mention you will need to either use GELs or create an image which powers the A72 before any JTAG action will be possible.  The SDK link and GEL link above have the necessary documentation and objects.  The fastest way to test would be to take a pre-built image and put it on an SD card then run it.  There are HS and GP images in the package.

For an all JTAG route, you would start by attaching to the R5, then run GELs which init the PLLs and PSCs (as the GEL examples show).  Once the A72 cluster is powered you can attach to JTAG and debug it.   This process composed of many, many of small steps as detailed in the code.  There is no step by step documentation for the custom path you are trying to blaze.

The R5-MCU is controlled via the APB-AP and its address range starts at APB:0x9D010000 (can can be seen in the APB coresight ROM table starting at 0x0).  The layout of the ARM debug registers matches the ARM coresight component documents for ARM and R5 implementation.  Attaching a debugger with a ~mature ARM stack is possible once things are powered and clocked but some sort of code.  There is no short cut magic from a jtag ap port.

Hello,

I wrote: "I have already successfully powered the A72 on another device via JTAG. However via the M3 via Acess Port 7". I have written an init sequence for power, clock etc. for this. Of course I implemented the code from the GELs (as described above). And it works directly after the reset on the GP device. But not with the HS-FS device.

According to your description, I now have to execute my init sequence (power, clock etc.) for the HS-FS device not via the M3 (JTAG AP7) but via the MCU-R5-0. Is that correct? But for this I need the JTAG AP number of the MCU-R5-0. Can you please tell me this number?

Regards,
Frank

Hello,

The all the non-M ARM cores are on the APB-AP on APSEL-1 (Access Port 1 in how you are referencing).  The R5-MCU is at APB:0x9D010000.  The register layout matches ARMs standard integration for R5.

Hello,

Thank you very much. I can now access the R5-MCU and my init sequence runs successfully (after a few address_offset adjustments). Access to the A72 now also works. 
Thank you very much for your support and patience.

Regards,
Frank