Is there any way to access Trusted RAM in normal domain?

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!!!

Parents
  • Hi 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,

    Zhenyu

  • Hi,

    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:

    • AxPROT[0] determines privilege - When asserted the access is privileged, and when not asserted the access is unprivileged
    • AxPROT[1] determines security - When asserted the access is Non-secure, and when not asserted the access is Secure (think SCR_EL3.NS bit)
    • AxPROT[2] determines type - When asserted the access is an instruction access, and when not asserted the access is a data access

    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

Reply
  • Hi,

    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:

    • AxPROT[0] determines privilege - When asserted the access is privileged, and when not asserted the access is unprivileged
    • AxPROT[1] determines security - When asserted the access is Non-secure, and when not asserted the access is Secure (think SCR_EL3.NS bit)
    • AxPROT[2] determines type - When asserted the access is an instruction access, and when not asserted the access is a data access

    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

Children
More questions in this forum