• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 101 subscribers
  • Views 213 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DRA821U: Configuration of secure memory with region-based firewall

Zinan Li
Prodigy 10 points
Part Number: DRA821U

Hi, engineers from Ti,

We're now working on configuring memory region 0x9e800000~0x9fbfffff to be only accessible from secure world.

We investigated the firewalls on https://software-dl.ti.com/tisci/esd/22_01_02/5_soc_doc/j7200/firewalls.html, 

but none of them matches the required memory range.

We tried to use TISCI_SET_FWL command to configure firewall 1280/2312 (whose owner is None according to the document).

The firewall configuration is successfully updated, but the requested region could still be read/written in normal world.

We also tried firewall 257 (according to the document https://www.ti.com/lit/an/spracx6/spracx6.pdf?ts=1655896002290&ref_url=https%253A%252F%252Fwww.google.com%252F)

This firewall could arbitrate memory access transaction. But only region 0 is configurable, therefore, could not fulfill our requirement to

only make certain region secure-memory only.

All the configuration is performed in ATF.

Could you please advice which firewall shall be used to configure secure memory on the device and how to configure them?

Thank you.

  • +1
    TI__Mastermind 23125 points

    Zinan, 

    what you looked up at:

        https://software-dl.ti.com/tisci/esd/22_01_02/5_soc_doc/j7200/firewalls.html

    is the list of firewalls programmed by Sysfw. These are NOT what you wanted. In your case, you wanted to protect DDR region to be only accessible by secure world. This can be achieved by:

    1. Program FWID 257. Note that you need to program two regions - one for background that permit everything; then a foreground region that only permit Arm secure transactions. The appNote should be a good example for this. 

    2. Note that this firewall only filters accessing of DDR from Arm subsystem. It does not protect access to the same DDR region, from other masters in the SOC, e.g., R5 cores. But if the R5 cores are not used/programmed by your system users, you may not need to worry about these. Otherwise, you will need to program all master firewalls accessing DDR. 

    To use the sysfw API, you may reference PDK example:

        <PDK>\packages\ti\drv\sciclient\examples\sciclient_fw_testapp

    But please note this example is intended to be built for R5 core, though the API are similar when you are calling from ATF.

    Full list of firewall IDs are in:

       <PDK>\packages\ti\csl\soc\j7200\srccsl_soc_firewalls.h

    where you can see 257 in the table. 

    Since sysfw did not program 257, you should first call the API to change the host ID to A72 secure, for both the background and foreground regions, then you can program the regions. please be sure to use 64bit address when you program start and end addresses. 

    I recall the appNote Kip wrote used R5 to program the firewall during SBL time. so just be aware in your case you are using A72. 

    Jian

  • 0 in reply to jian35385
    Prodigy 10 points

    Hi, Jian,

    After changing owner of the firewall region0 and region1 to 10(the host id defined in ATF),  we are now able to configure memory to be accessible only in secure world from A72. Thank you.

    But there're further more questions regarding configuration of firewalls,

    With permission register set to 0x100FF, we could read the permission 0x188FF with TI_SCI_GET_FWL. Why the Debug bit is always set in the permission register?

    Zinan

  • +1 in reply to Zinan Li
    TI__Guru* 93811 points

    Hi Zinan,

    The firewall DEBUG Permission Bits (SEC_SUPV_DEBUG, SEC_USER_DEBUG, NONSEC_SUPV_DEBUG, NONSEC_USER_DEBUG) will always be set set high when a firewall is programmed.  This is expected behavior.  

    Regards,

    kb