I am using Juno Board with Linaro's trusted firmware.
For the convenience of debugging, I want to access the Trusted RAM(0x04000000-0x04040000) in normal domain, and directly flash the image into memory instead of erasing the flash every time. But it seems that the normal domain has no privilege to access that address region. I attempted to add that memory region into TZC-400 with corresponding attribute, but it did not work.
But I think there should be some approach to make that region accessible to normal domain. Does anyone know the details?
Thanks very much for any help!!!
Hi Ash,
Thanks for your reply. Sorry for the misspelling, it works now.
And for the question about refresh image in memory, I think I will email the support as your suggestion. I really appreciate your kind guide, thanks so much!!!
Zhenyu
Hi,
You've misspelled the prefix. You put AXI<PORT=1>, but it needs to be AXI<PROT=1> (or AXI<PROT=0> or AXI<PROT=4> or AXI<PROT=5>). Remember that the naming here is based on the AMBA AXI AWPROT and ARPROT signals, which are collectively referred to as AxPROT, with the "PROT" being short for "PROTECTION".
I tried this and it worked:
restore /home/ash/blob.bin binary AXI<PROT=0>:0x4023000 Restoring section AXI:0x0000000000000000 to AXI:0x000000000000D7A3 into memory AXI:0x0000000004023000 to AXI:0x00000000040307A3restore /home/ash/blob.bin binary AXI<PROT=1>:0x4023000 Restoring section AXI:0x0000000000000000 to AXI:0x000000000000D7A3 into memory AXI:0x0000000004023000 to AXI:0x00000000040307A3restore /home/ash/blob.bin binary AXI<PROT=4>:0x4023000 Restoring section AXI:0x0000000000000000 to AXI:0x000000000000D7A3 into memory AXI:0x0000000004023000 to AXI:0x00000000040307A3restore /home/ash/blob.bin binary AXI<PROT=5>:0x4023000 Restoring section AXI:0x0000000000000000 to AXI:0x000000000000D7A3 into memory AXI:0x0000000004023000 to AXI:0x00000000040307A3
restore /home/ash/blob.bin binary AXI<PROT=0>:0x4023000
Restoring section AXI:0x0000000000000000 to AXI:0x000000000000D7A3 into memory AXI:0x0000000004023000 to AXI:0x00000000040307A3
restore /home/ash/blob.bin binary AXI<PROT=1>:0x4023000
restore /home/ash/blob.bin binary AXI<PROT=4>:0x4023000
restore /home/ash/blob.bin binary AXI<PROT=5>:0x4023000
As expected, trying to use AXI<PROT=2>, AXI<PROT=3>, AXI<PROT=6>, or AXI<PROT=7> will not work, because then AxPROT[1] will be asserted which makes the access Non-secure.
Regarding your question of whether this is feasible, my initial thought would be no because your translation table mappings are likely going to be broken since you're changing the size of the image, but this is also probably going beyond the scope of what we can help you with here on these forums. Assuming you have an entitlement to support, it would probably be a good idea to email support@arm.com at this point.
Thanks a lot for your patient. I think I got your idea. But it seems interesting that the restore command did not support AXI prefix.
When I use AXI prefix in the memory window, it's perfect. But if I use it in the import memory dialog or in restore command, it did not work.
Let me describe what I attempt to do first. As you know, I am using Trusted Firmware provided by Linaro. It is really a boring thing that every time I modified the source code, I have to erase all things in the flash and re-flash them again. As I am using Android as OS of Normal domain, it takes really a long time to re-flash and reboot. So I want to just import the image to the memory, then I won't have to wait for so long.
As my modifications are all in BL31, so I found the address of BL31 image in memory and try to override it. My attempt looks like this:
1) pause the cores in EL1.
2) disable MMU of EL3.
3) use restore command or import memory dialog to import the image to BL31 address (0x4023000).
4) enable MMU of EL3 again.
5) restore the cores.
In step 3, if I use command like the following
restore "/home/zhenyu/juno/workspace/arm-tf/build/juno/debug/old_bl31" binary AXI<PORT=1>:0x0000000004023000
Then DS-5 threw an error indicating "Memory parameter "PORT" not-applicable for address space "AXI". The prefix "EL3" works perfectly and also the AXI prefix works perfectly in memory window.
Another thing is, do you thing my approach is feasible? Every time I just modify few codes in an C function invoked by SMC handler, so I guess this may work. But in practice, it depends. Sometimes it works and sometimes the system halts right after step 5. That's strange. Because after step 5, the system should still in EL1, and I didn't modify anything about EL1.
Also, my board is juno R1, maybe you also know that now DS-5 has some bugs so I have to connect to the board use R0 option. And when connected to the board, sometimes it shows that all cpus are "held in reset" or "powered down". Then if I press the interrupt button in this situation, nothing will happen. I have to make the board "doing sth", like open an application, and the cpu status will become "running" for a short period. If I pressed the button in that period, the cores will be paused. It looks like a speeding race . Moreover, even the core is paused, the Command window may keep flooding with some log information like,
Execution stopped in EL1h mode at EL1N:0xFFFFFFC00009A4E8 On core Cortex-A53_0 (ID 2) EL1N:0xFFFFFFC00009A4E8 RET Execution stopped in EL1h mode at EL1N:0xFFFFFFC00009A4E8 On core Cortex-A53_0 (ID 2) EL1N:0xFFFFFFC00009A4E8 RET Execution stopped in EL1h mode at EL1N:0xFFFFFFC00009A4E8 On core Cortex-A53_0 (ID 2) EL1N:0xFFFFFFC00009A4E8 RET Execution stopped in EL1h mode at EL1N:0xFFFFFFC00009A4E8 On core Cortex-A53_0 (ID 2) EL1N:0xFFFFFFC00009A4E8 RET
That't terrible, do you have any same experience?
Thanks so much for your reply.
No problem
To understand the AXI<PROT=1>: prefix, you first need to understand how Secure and Non-secure accesses are exported onto the bus.
The AMBA AXI and ACE protocol specification is available for download as a PDF here from ARM Infocenter (note that you'll need to create a free account).
Specifically, you'll want to take a look at Section A4.7 "Access Permissions". Basically, there are two signals used to define the access permissions for accesses - ARPROT[2:0] for reads, and AWPROT[2:0] for writes, and these are collectively referred to as AxPROT.
The encoding of AxPROT is as follows:
Whether your system actually does anything with AxPROT[0] and AxPROT[2] is IMPDEF, but the important one is AxPROT[1] for determining the security.
When we do AXI<PROT=1>:, we're asserting AxPROT[0] and deasserting AxPROT[2:1], i.e. we're saying this is a Privileged Secure Data access. I played around on the Juno and you can for example do AXI<PROT=0>:, which is going to deassert AxPROT[2:0], making it an Unprivileged Secure Data access. This worked for reprogramming the TZC-400 (requires Secure accesses). However, if we use AXI<PROT=2>:, this will not work for reprogramming the TZC-400 as now AxPROT[1] is asserted which makes the access Non-secure.
You can use the AXI<PROT=1>: for viewing memory in the debugger, so I imagine you should be able to use it to load your image too.
For example, when at EL2, entering 0x04000000 into the memory window shows red boxes, i.e. we can't access Trusted RAM from the Normal world. Changing the address to AXI<PROT=1>:0x04000000 bypasses the processor and ensures that the accesses are Secure, so now we can see Trusted RAM in the memory window even though the processor is in EL2 in the Normal world.
I hope that helps,
Ash
You saved me again. I am really appreciate that!!!
I tried the prefix EL3, and that works!! But I don't quite understand how the prefix "AXI<PORT=1>" works. I think I should really look through some manual, do you know any manual talks about this? I looked up the DS-5 debugger command reference, but got nothing about this.
Thanks again for your help!
Regards,
No, there is no way to make that region accessible to Non-secure accesses. Reprogramming the TZC-400 won't work, as that's only used to control the security attributes of the memory that sits behind it (i.e. DDR).
This is a deliberate design decision to allow for a Trusted Execution Environment in the Secure world that is isolated from software running in the Normal world. One example use case for this is to host Trusted Services in the Secure world, such as for securely processing payments on a mobile device, or for DRM-protected media content playback. These Trusted Services can then be requested by software running in the Normal world (i.e. Linux).
That whole paradigm would be inherently broken if Secure-only areas on the memory map (such as Trusted RAM) were somehow accessible to Non-secure accesses
Unfortunately I haven't had a chance to try this, but if you're using DS-5 to upload your image to the board, you could try prefixing the load address with either EL3: or AXI<PROT=1>:. You can see us using the AXI<PROT=1>: prefix in this tutorial, as this ensures that the access is made as a Secure access. Failing that, you can try prefixing with EL3:, but note that this will use EL3's virtual address space, so you'd probably want to disable the MMU at EL3 before trying that one.
Hope that helps,
Ash.
View all questions in Arm Development Platforms forum