• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 29 subscribers
  • Views 921 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.

[FAQ] MCU-PLUS-SDK-AM243X: R5F MPU configuration in MCU+ SDK

Prasad Jondhale
Mastermind 27743 points
Part Number: MCU-PLUS-SDK-AM243X

Hi TI Experts,

The first entry in the MPU configuration for AM263x, AM273x and AM243x contains one big section like below -

    {

        .baseAddr = 0x0u,
        .size = MpuP_RegionSize_2G, //for AM273x it is 4G
        .attrs = {
            .isEnable = 1,
            .isCacheable = 0,
            .isBufferable = 0,
            .isSharable = 1,
            .isExecuteNever = 1,
            .tex = 0,
            .accessPerm = MpuP_AP_S_RW_U_R,
            .subregionDisableMask = 0x0u
        },
    },
This MpuP_RegionSize_2G basically covers 0x0U to 0x80000000U and grant all regions with RW access including all TCMA and TCMB and the Onchip RAM.
So it looks like the SDK example attempt to unlock all 2G space, then, configure each subsection later.
Question:
1. Why this unlock-all-first-then-config-individual step is needed?
2. Seems like If I remove the first 2G unlock step, my app cannot run and got trapped to the HwiP abort handler when doing hwiP_init() inside system_init(). Could you help me understand what was the problem if I don't unlock the whole 2G first?
3. This 2G unlock seems risky to me because it by default open all memory access to that CPU and we probably want the opposite - explicitly allow a CPU to have write access to certain regions that, if not specified, it should be read-only by default. Please let me know if we have a better way to handle this MPU init. 
 
Regards,
Prasad
  • 0
    TI__Mastermind 27743 points

    Hi,

    Prasad Jondhale said:
    1. Why this unlock-all-first-then-config-individual step is needed?

    As there are limited MPU regions available (only 16) the approach followed is - 

    Mark a background region for full adressable space (4G/2G).-

    This region is marked as

    - Non executable

    - Supervisor R/W

    - User Read

    - Strongly ordered Non Cacheable memory

    The primary use of this background region is to allow access to most memory mapped registers without adding explicit MPU entries for each register space accessed in application. Based on the number of discontinuous register regions that need access it is possible to run out of the 16 MPU entries.

    Other MPU entries then mark different executable code regions, cacheable regions etc.

    This background MPU region is not mandatory and it is possible to set MPU entries with only explicit regions accessed by application but that requires identifying every register access/memory access and coming up with MPU regions that allow access to these regions while meeting the constraint of not exceeding 16 MPU entries. This is best done when application development is complete so that MPU entries can be tuned to specific application's memory access. Recommendation is to use permissive background region during initial app development and once functionality is completed to remove the background regions and create explicit MPU entries if it is a requirement.

    The SDK tries to use a common MPU configuration that works for all applications and hence uses this large background region

    Prasad Jondhale said:
    2. Seems like If I remove the first 2G unlock step, my app cannot run and got trapped to the HwiP abort handler when doing hwiP_init() inside system_init(). Could you help me understand what was the problem if I don't unlock the whole 2G first?

    Regarding below the data abort is due to missing MPU entries for R5 VIM RAM, VIM registers . These have to be explicitly added if background MPU region is removed.

    Prasad Jondhale said:
    3. This 2G unlock seems risky to me because it by default open all memory access to that CPU and we probably want the opposite - explicitly allow a CPU to have write access to certain regions that, if not specified, it should be read-only by default. Please let me know if we have a better way to handle this MPU init. 

    As mentioned earlier, the one big region is not mandatory and we add it in SDK to keep it generic for all apps. Customers are free to remove it and add individual entries.

    Regards,

    Prasad (with help from Badri)