I am working with an LS1043A (NXP) branded ARMv8 A53. I am trying to bring the board up in a secure way requiring me to write to a few configuration registers before releasing the CPU (for testing purposes). The steps outlined for a similar NXP device (LS1021) uses their toolchain (Code Warrior/Core Warrior TAP) to connect to the device under reset and write to memory. I reached out to NXP and was redirected to the DS5/DSTREAM community.
In short, when the CPU cores are being held in reset how can we configure DS5 to have read/write access to memory? Specifically, I am interested in the registers of the Security Fuse Processor (SFP) which are contained in the CCSR block, if the access region makes any difference.
What I am seeing in DS5 is the following:
Hi oncepragmatic,
You can probably do it through the MEM-AP components in the design - the cores are connected, probably, to an APB-AP accessor which is the thing fronting all the accesses to the cores. A memory write via the core goes via the APB-AP to the core debug logic, out through the core into the design. But you can also use the AHB-AP or AXI-AP in a design to go around the core and direct to the interconnect. There's a nice diagram in a blog here.
What we really need to do is figure out how to access it. Usually a system will come up with a prefixed memory space, such as AHB: or AXI: (or AXI_0:), for example. To get DS-5 to tell you what that prefix is, you can use the command
info memory
It should list the addressing prefixes available to the debug connection. Note that N:, S:, NP: and SP: etc. will go through cores, which are in reset, so you won't be able to use these. You should be able to see one like AHB: or AXI:, hopefully.
Once you know which prefix it is, then you may be very interested to know how to access the bus with custom attributes. For instance, I am fairly sure that the Secure Fuse Processor would require some kind of Secure access (i.e. AxPROT[1] would be 0 for AXI, or for AHB the corresponding HNONSEC would be 0.) You can apply those parameters with the address prefix, as follows to read, for example, a particular memory location (or to use in the Memory view of DS-5):
inspect /x AXI<PROT=1>:0xFFE00000memory set AXI<PROT=1,verify=0>:0xFFE00000 32 ((unsigned int) 0xDEADBEEF)
inspect /x AXI<PROT=1>:0xFFE00000
memory set AXI<PROT=1,verify=0>:0xFFE00000 32 ((unsigned int) 0xDEADBEEF)
Those parameters will be defined in two places. One, how DS-5 expects you to write them out, is returned by the command:
info memory-parameters
And the other would be the specification for example the AHB Access Port (AP) in the CoreSight SoC-400 TRM and the corresponding AMBA specification for whichever AP it is in the system. The bits in the Control and Status Word (CSW) register for each AP define which signals could be modified per-transaction, and the AMBA spec will tell you what the bit positions for each attribute will be. For AXI, PROT=1 means AxPROT[4:0] = 00001 which implies a Secure, Privileged transaction. Depending on the SoC component you should be able to work out the expected attributes, set the right parameters for the appropriate bus prefix, and perform the memory access operations you need.
Some friendly advice, though: please be careful! When dealing with things like eFUSE or OTP blocks, accidentally changing things in memory windows (you can click a word and edit it in-place!) may be a phenomenally bad idea and put your system into a permanently unusable state. Using the wrong attributes for accesses may also put your system in a more temporary unusable state, for instance if it causes a Security Controller Alarm which resets or prevents access to memory. It is sometimes not easy to prevent such accesses with a full UI debugger!
If you want to do much the same thing without invoking the UI, there is a command-line version of the DS-5 debugger (which will help prevent mis-clicking on a view), and also a low-level tool called CSAT which may be more suitable.
This is a wonderfully detailed answer! This has helped explain a bit of the terminology I have seen while researching this problem and has given me insight into the depth of the problem. As far as the output of the info memory command, we have:
Num Enb Low Addr High Addr Attributes Description1: y SP:0x0000000000000000 SP:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using secure world physical addresses2: y S:0x00000000 S:0xFFFFFFFF rw, nocache, verify Memory accessed using secure world addresses3: y NP:0x0000000000000000 NP:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using normal world physical addresses4: y N:0x00000000 N:0xFFFFFFFF rw, nocache, verify Memory accessed using normal world addresses5: y H:0x00000000 H:0xFFFFFFFF rw, nocache, verify Memory accessed via hypervisor address6: y EL3:0x0000000000000000 EL3:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using EL3 addresses7: y EL2:0x0000000000000000 EL2:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using EL2 addresses8: y EL1S:0x0000000000000000 EL1S:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using EL1 secure world addresses9: y EL1N:0x0000000000000000 EL1N:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using EL1 normal world addresses10: y APB_0:0x00000000 APB_0:0xFFFFFFFF rw, nobp, nohbp, nocache, noverify APB bus accessed via AP 1 (CSMEMAP_1)11: y AHB_0:0x00000000 AHB_0:0xFFFFFFFF rw, nobp, nohbp, nocache, noverify AHB bus accessed via AP 0 (CSMEMAP_0) HPROT=67 AHB bus accessed via AP 0 (CSMEMAP_0)
Num Enb Low Addr High Addr Attributes Description
1: y SP:0x0000000000000000 SP:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using secure world physical addresses
2: y S:0x00000000 S:0xFFFFFFFF rw, nocache, verify Memory accessed using secure world addresses
3: y NP:0x0000000000000000 NP:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using normal world physical addresses
4: y N:0x00000000 N:0xFFFFFFFF rw, nocache, verify Memory accessed using normal world addresses
5: y H:0x00000000 H:0xFFFFFFFF rw, nocache, verify Memory accessed via hypervisor address
6: y EL3:0x0000000000000000 EL3:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using EL3 addresses
7: y EL2:0x0000000000000000 EL2:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using EL2 addresses
8: y EL1S:0x0000000000000000 EL1S:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using EL1 secure world addresses
9: y EL1N:0x0000000000000000 EL1N:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using EL1 normal world addresses
10: y APB_0:0x00000000 APB_0:0xFFFFFFFF rw, nobp, nohbp, nocache, noverify APB bus accessed via AP 1 (CSMEMAP_1)
11: y AHB_0:0x00000000 AHB_0:0xFFFFFFFF rw, nobp, nohbp, nocache, noverify AHB bus accessed via AP 0 (CSMEMAP_0)
HPROT=67 AHB bus accessed via AP 0 (CSMEMAP_0)
Sorry for the poor formatting. So, then, it seems we do have an AHB pathway.
So, then, is the default memory namespace used by DS5 one of the first few entries that goes through the core directly?
oncepragmatic,
The default memory space is essentially virtual addressing, in the current exception level and security state. DS-5 is designed from the perspective that it'll be debugging ARM cores so it will try and access through the core. If the cores are powered down or in reset, it will simply fail.
Using AHB_0: as a prefix, then, will get you to where you want to go. The HPROT= value (as in AHB_0:<HPROT=nnn>) is the top 8 bits of the AHB-AP.CSW register. I'm actually a little nonplussed about the '67' value you mentioned is 0x43 which corresponds to SProt=1, Prot=3 which is basically Secure, Privileged, Data.
Should work. Again, though, be careful
Ta,
Matt