• Locked Locked
  • Replies 10 replies
  • Subscribers 117 subscribers
  • Views 6585 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

syuji biwa
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.
  • Note: This was originally posted on 19th August 2013 at http://forums.arm.com

    I found the answer by myself.

    1. PL310's background-operation(inv.way etc..) is executing in non-secure.
    2. By secure-interrupt, dispatch to secure.
    3. In secure, wait for complete background-operation.(It is read operation.)
    4. try to execute a write-operation to PL310' register.
       no 'DATA-ABORT' is occured.

    But,,,
    New question.

    In 'MultiCore System'.
    My secure-monitor is running on CORE0 only.

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

    Do I must control exclusive-access for PL310, secure and non-secure ?
    (ex. spinlock)

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

    Thank you for the reply.

    That is, between secure and non-secure, Exclusive control is required.
    Or, Background operation is not used. (Atomic operation Only.)

    Followed Situation is bad ?

    secure:
    OS RealTimeOS (ex. iTRON)
    Interrupt FIQ
    TickTimer1 (FIQ)

    non-secure:
    OS Linux
    Interrupt IRQ
    TickTimer2 (IRQ)

    1. Linux running.
    2. Linux execute flush_range. (called for l2x0_flush_all. background operation)
    3. Linux wait for complete L310.
       (IRQ is disabled, but FIQ is enabled.)
    4. TicmTimer1 expired.
    5. FIQ accept. -> change to secure-mode.
    6. RealTimeOS execute interrupt handler.(Tick handler)
    7. RealTimeOS execute cache operation.
    If (2.)-operation is not complete, (7.)'s operation is abort.

    Is this TRUE ?

    How do Other System have avoided ?
    My problem is that a good method is not found.

    (I am sorry for poor English.)
  • Note: This was originally posted on 20th August 2013 at http://forums.arm.com

    I'm sorry, I'm mistake.

    My question is only by the multi-core system.
    The last example was not good.

    A suitable example :

    core0:
      SecureOS (I plan to create this.)
    core1:
      Non-secureOS (Linux)

    Is exclusive control required for PL310 between SecureOS and Non-secureOS?
    If true, do SpinLock need to implemented between SecureOS and Non-secureOS?
    Common memory required for SpinLock?

    And, one more question.

    If SecureOS uses L1-cache only(L1:cacheable L2:non-cacheable page),
    L2-cache-sync-operation require?

    For example (PL310 enabled)
    DMA transfer.
    1. write to normal-memory.
    2. DMB execute.
    3. write to DMA register(device-memory).
    4. DSB execute.
    Does PL310 always write in as turn? (1->3)
    Or Turn is not guaranteed?
  • Note: This was originally posted on 21st August 2013 at http://forums.arm.com

    So, Always(is not related secure and non-secure), need the exclusive control?
    I understand.

    I tested follow.

    1. execute PL310's background operation.
    2. As soon as, execute cache_sync operation.(write to PL310 register)
    3. DATA-ABORT occured.

    one more,
    1. (CORE0) execute PL310's background operation.
    2. (CORE0) wait for complete background operation.(read from PL310 register) (never DATA-ABORT)
    3. (CORE1) execute cache_sync operation.(write to PL310 register)
    4. (CORE1) DATA-ABORT occured.

    my problem is How implement a SecureOS.

    In generary, non-secureOS is allows FIQ-interrupt always.(can not disable FIQ.)
    Linux's spin_lock_irqsave() can not disable FIQ.
    So that, Between secure and non-secure, Can exclusive-control implement?


    ------------------------------------------------------------------------
    Sorry, 「non-cache and device access order」question is written independently.
  • Note: This was originally posted on 21st August 2013 at http://forums.arm.com

    > Why do you think you need to use the background operations?

    I want to play 'Linux' on non-secure world.

    Linux excutes follow-code.
    -------------------------------------------------------------------------
    cache-l2x0.c
    l2x0_flush_range()
      l2x0_flush_all()
          __l2x0_flush_all()
              writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_INV_WAY);
              ------ 'This is background-operation.' ------
              cache_wait_way(l2x0_base + L2X0_CLEAN_INV_WAY, l2x0_way_mask);
              cache_sync();
    -------------------------------------------------------------------------
  • Note: This was originally posted on 24th August 2013 at http://forums.arm.com

    Thanks.

    > you may need to set up exclusive access
    If non-secureOS is hang in spinlock, SecureOS nerver get a spinlock.
    When secureOS try to get a spinlock in FIQ, secureOS is dead-lock.

    SecureOS's implementation is so difficult.
    SecureOS may be better not to use cache. (no-MMU only.)
  • Note: This was originally posted on 21st August 2013 at http://forums.arm.com

    I still don't quite understand why you are so keen on the background operations. Assuming you have tied FIQ to secure then the Non-secure world cannot mask interrupts. If you are running an SMP system then stopping all of the cores to run a background operation is rather expensive. 

    Why do you think you need to use the background operations?
    [size=2]
    [/size]
    [size=2]Use the atomic set-way operations, then you don't need any synchronization.[/size]
  • 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]

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

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


    You must ensure any background operation has completed before starting another one; it doesn't matter if that is secure or non-secure. It is relatively unusual to want to nuke the whole cache though, and if you iterate set-way you can avoid this need for exclusivity (each individual operation is atomic in that case).


    I'm not sure why you are seeing data aborts though - the execution of background operations should be transparent to the CPU provided you honour the requirements of the flush (don't access ranged while they are being cleaned, which may need you to disable interrupts, etc). [See section "Register 7, Cache Maintenance Operations" in the manual on infocenter.arm.com].
    [color=#222222][font=Arial, Helvetica, sans-serif] [/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif]Side note: are you sure all of the data in the cache is valid? It is possible to write allocate in the L2 cache to an address which doesn't exist - the aborts are only visible when the cache is flushed (as imprecise aborts).[/font][/color]

    HTH,
    Iso
  • Note: This was originally posted on 20th August 2013 at http://forums.arm.com

    Well as I mentioned in my last post, to meet the spec for the L2CC operations you have to guarantee that you don't access memory ranges which may be in a cache way which is being cleaned by a background operation. [color=#222222][font=Arial, Helvetica, sans-serif][size=2]In general it the therefore _impossible_ to run arbitrary code while a background operation is running; you can pretty much guarantee you will touch at least one of the locked ways. This therefore means you to disable interrupts, etc, while performing background operations and stop other cores running which could touch the cache.[/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]Again, it is very [/size][/font][/color][color=#222222][font=Arial, Helvetica, sans-serif][size=2]unusual[/size][/font][/color][color=#222222][font=Arial, Helvetica, sans-serif][size=2] for code to want to nuke the whole cache, precisely because it is very hard to make safe; for full SMP systems the atomic set-way instructions exist.[/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]HTH,
    Iso[/size][/font][/color]