This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

TrustZone with PL310

Note: This was originally posted on 17th August 2013 at http://forums.arm.com

I plan to use a simple 'TrustZone Monitor'  with PL310(L2CC).
In non-secure, I will play a Linux-Kernel.

One problem.
1. PL310's background-operation(inv.way etc..)  is executing in non-secure.
2. By secure-interrupt, dispatch to secure.
3. In secure, try to execute a write-operation to PL310' register.
May be happen 'DATA-ABORT'.

Do I must control exclusive PL310  secure and non-secure ?

Please help me.
Parents
  • Note: This was originally posted on 22nd August 2013 at http://forums.arm.com

    OK - I think the answer is "it depends" ...

    The two critical parts of the spec are:

    [size=2]During background operations, the cache controller considers the targeted ways locked until it treats them. Therefore the controller does not permit read or write misses to access that way. It does however permit read or write hits to access the way, therefore there can still be dirty lines at the end of a clean operation.[/size][size=2]
    [/size]
    [size=2]
    [/size]
    [size=2]and [/size]
    [size=2]
    [/size]
    [size=2]
    [/size][size=2]Software must not perform a clean instruction on a region when it contains active data, that is, data accessed during the clean operation. To ensure that a clean operation is completed, mask the interrupts. Also ensure that the software polls the Cache Operation Register to check if the operation is complete.
    [/size]
    [size=2]
    [/size]
    [size=2]The first [/size]guarantee[size=2] is "free" in terms of implementation; it will just reduce performance of the "other world" as the CC won't allocate new data into that cache way until the background operation has completed. [/size]
    [size=2]
    [/size]
    [size=2]The issue comes around the second part. If you have "active" data in the cache then you need to ensure exclusive access. For Linux itself most of the cache ops are already inside spinlocks, so they are safe. If you cannot mask FIQ then you may need to set up exclusive access AFAICT (or your secure OS monitor code has to check the cache operations have completed).[/size]

Reply
  • Note: This was originally posted on 22nd August 2013 at http://forums.arm.com

    OK - I think the answer is "it depends" ...

    The two critical parts of the spec are:

    [size=2]During background operations, the cache controller considers the targeted ways locked until it treats them. Therefore the controller does not permit read or write misses to access that way. It does however permit read or write hits to access the way, therefore there can still be dirty lines at the end of a clean operation.[/size][size=2]
    [/size]
    [size=2]
    [/size]
    [size=2]and [/size]
    [size=2]
    [/size]
    [size=2]
    [/size][size=2]Software must not perform a clean instruction on a region when it contains active data, that is, data accessed during the clean operation. To ensure that a clean operation is completed, mask the interrupts. Also ensure that the software polls the Cache Operation Register to check if the operation is complete.
    [/size]
    [size=2]
    [/size]
    [size=2]The first [/size]guarantee[size=2] is "free" in terms of implementation; it will just reduce performance of the "other world" as the CC won't allocate new data into that cache way until the background operation has completed. [/size]
    [size=2]
    [/size]
    [size=2]The issue comes around the second part. If you have "active" data in the cache then you need to ensure exclusive access. For Linux itself most of the cache ops are already inside spinlocks, so they are safe. If you cannot mask FIQ then you may need to set up exclusive access AFAICT (or your secure OS monitor code has to check the cache operations have completed).[/size]

Children
No data