• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 1330 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Dynamically enable / disable MPU regions

Owain Phillips
Intellectual 370 points

Other Parts Discussed in Thread: HALCOGEN

Hi,

We are using MPU; and I would like to define one region allowing first MB of internal FLASH to be executed; but not read or written.

Other code running from a "user" program in another region (also running priviledged); can then not read this protected region.


But can I stop the "user" program from reprogramming the MPU and gaining access to this region?
Because this "user" code is running privledged he can run the priviledged move to/from co-processor registers; hence reprogam the MPU.

Is the only way to stop the user program from reading that region to ensure it is running in user mode?

I need to achieve copy protection somehow. Is only solution to implement a "system" interface and ensure user code is really running in user mode; going over system interface to enter system mode to access protected resources?

Regards,

Owain

  • 0
    TI__Guru 69070 points

    Owain,

    You should study the FreeRTOS OS that is included with HalCoGen.  It handles the MPU and allows you to create tasks that run in User mode (without privilege) so that they can be restricted from accessing various memory regions.

    Reason I recommend studying (if not just using) the FreeRTOS port is that it's a pretty complicated topic - a lot more than just setting a register bit anyway.  So you'll want to look at a 'complete solution' like the FreeRTOS os to understand it.


    -Anthony

  • 0 in reply to Anthony F. Seely
    Intellectual 370 points

    Hi Anthony,

    I understand what you are saying and this is the route I want to take but this is quite a large jump to start with.

    Here is MPU config configured via halcogen 4.0.0....

    Above configuration is running; then I run the following code.....

    void systemProtectInterlectualProperty( void )
    {
    _mpuDisable_();
    _mpuSetRegion_( mpuREGION1 );
    _mpuSetRegionBaseAddress_( 0x00000000 );
    _mpuSetRegionTypeAndPermission_( MPU_NORMAL_OIWBWA_NONSHARED, MPU_PRIV_NA_USER_NA_EXEC );
    _mpuSetRegionSizeRegister_( mpuREGION_ENABLE | MPU_512_KB );
    _mpuEnableBackgroundRegion_();
    _mpuEnable_();
    }

    At _mpuEnable_() the processor hangs up on the isb command. I assume this is the fetches to refill the cache breaking

    Is this mode OK; can a region really be not read/writeble from both user and exec and still executable; if I change that mode to MPU_PRIV_RW_USER_RW_EXEC we run OK; but I don't restrict access to anything.

    Regards,

    Owain

  • 0 in reply to Owain Phillips
    Intellectual 370 points
    I have now blocked access from our runtime firmware to our bootrom loaders using MPU. Looking in debugger after switching MPU modes those regions respond with aborts...

    But I would really like to block that the runtime firmware itself is readable from Priv code; I still want it to be executable.
    Hence my earlier question to the mode MPU_PRIV_NA_USER_NA_EXEC.

    Is this possible?
  • 0 in reply to Owain Phillips
    TI__Guru 69070 points

    Owain,

    This is a statement from the CPU's TRM, section 7.1.1.   See http://infocenter.arm.com/help/topic/com.arm.doc.ddi0460d/DDI0460D_cortex_r5_r1p2_trm.pdf

    "To ensure correct operation, only a memory region that has permission for data read access can execute instructions."

    That's what you were asking about, correct?