• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 2093 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.

Unaligned data fault and MMU on Sitara running SysBios

Mario Giovanni Casali
Intellectual 360 points
Other Parts Discussed in Thread: SYSBIOS, AM3357

Hello.

I'm working on ecat_appl example contained in SDK 1.1.0.4 and so I am forced to use packed structures to be exchanged with PRUs (for example: variable sSyncManOutPar, which is initialized in function COE_ObjInit in file coeappl.c); note that some fields in those structures are unaligned (even if the whole structure is aligned, of course).

Well, if those packed structures are located at an address which is not listed in the list passed to MMUInit function, no problem arises.
If I add a mmu entry in the list for MMUInit telling that that piece of memory has flags 0x00000000 (that is, neither cachable nor bufferable), a "data error" fault arises when the machine instruction STR is executed on an unaligned 32-bit field (for example: sSyncManOutPar.u32MinCycleTime).

Can somebody help me? I would like to know what are the relationships between alignment checking, mmu (and possibly cache).
What are the attributes of a range of addresses which is not explicitly passed to MMUInit function?

Thank you.

Mario G. Casali
System Electronics
Italy

  • 0
    TI__Guru**** 393215 points

    Moving this to the SYS/BIOS forum.

  • 0
    TI__Expert 8175 points

    Hi Mario,

     To get started, can I know what version of SYS/BIOS you're using and which Sitara device you are running on?

    Thanks,

    Moses

  • 0 in reply to Moses Isang
    Intellectual 360 points

    Hello Moses.

    I'm using AM3357 and the software environment suggested by SDK 1.1.04, that is XDC 3.35.3.72, SYSBIOS 6.35.4.50 and UIA 1.3.1.08; some times ago, I tried to upgrade to newer versions of SYSBIOS (from 6.37 up to TI-RTOS for Sitara 2.0.1.23), but found other problems (see my post "EtherCAT problems using TI-RTOS for Sitara and SDK 1.1.0.4" and replies from TI guys); maybe, other problems are not really "other", but are the same problem: my misunderstanding about how to use mmu and cache and things like that in a proper way.

    Is there some document explaining relationships among platforms, mmu, cache?

    Thank you for your time.

    Mario

     

  • 0
    TI__Mastermind 47721 points

    Hi,

    Mario Giovanni Casali said:

    Well, if those packed structures are located at an address which is not listed in the list passed to MMUInit function, no problem arises.

    If I add a mmu entry in the list for MMUInit telling that that piece of memory has flags 0x00000000 (that is, neither cachable nor bufferable), a "data error" fault arises when the machine instruction STR is executed on an unaligned 32-bit field (for example: sSyncManOutPar.u32MinCycleTime).

    What are the attributes of a range of addresses which is not explicitly passed to MMUInit function?

    http://community.arm.com/thread/3631 : This behavior is expected when you make unaligned access to strongly ordered memory in Cortex-A architecture.

    However this is not advised anyway for application data structures as this will significantly reduce performance due to increased access cycles to DDR memory

    DDR, SRAM and OCMC_SRAM are already initialized by SYS/BIOS AFAIK. Peripheral register space is typically initialized using MMUInit function by application (this is normally application specific)

    For knowing SYS/BIOS platform config, 

    Goto Menu, Tools > RTSC Tools > Platform > Edit/View.

    Select platform package repo. bios_6_x_x_\packages

    Select package name, ti.platforms.evmAM3359, Select GPP, click next

  • 0 in reply to PratheeshGangadhar
    Intellectual 360 points

    Hello Pratheesh.

    All you say is ok; but my question is: where have I taught the builder (and mmu) that unlisted memory areas are not strongly ordered? and where have I taught that listed areas are strongly ordered?

    As far as I know, the only flags I can set are the following:

    #define SYS_MMU_BUFFERABLE      1
    #define SYS_MMU_CACHEABLE       2
    #define SYS_MMU_SHAREABLE       4
    #define SYS_MMU_NO_EXECUTE      8

    Bye.

    Mario

  • 0 in reply to Mario Giovanni Casali
    TI__Mastermind 47721 points

    Hi,

    You can get more details on this from ARM documentation : http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344f/Chdhbjjb.html

    As a quick summary

    Strongly ordered: No flags are set (not buffer-able, not cache-able) : Access is not optimal

    Device: buffer-able, not cache-able : Recommended for peripheral registers

    Normal: buffer-able, cache-able, shareable : Recommended for regular memory

  • 0 in reply to PratheeshGangadhar
    Intellectual 360 points

    Hi Pratheesh.

    I've not forgotten you; simply, I'm trying to check if your answer fits with my real case.

    I've found that my platform file (describing memory areas in my board) is translated to the following piece of code in file app_pea8fnv.c (generated during build process of my "app"; comments are mine):

    Void ti_sysbios_family_arm_a8_Mmu_initTableBuf__I(ti_sysbios_family_arm_a8_Mmu_Module_State *mmuModule)
    {
         mmuModule->tableBuf[384]  = 0x18000e0e;  // Battery-backup SRAM area (512 KB; RW)
         mmuModule->tableBuf[388]  = 0x18400e0e;  // Battery-backup SRAM area (512 KB; RW)
         mmuModule->tableBuf[392]  = 0x18800e0e;  // Battery-backup SRAM area (512 KB; RW)
         mmuModule->tableBuf[396]  = 0x18c00e0e;  // Battery-backup SRAM area (512 KB; RW)
         mmuModule->tableBuf[1026] = 0x40200e0e;  // On-chip RAM_LO and RAM_HI
         mmuModule->tableBuf[1027] = 0x40300e0e;  // On-chip OCMC_SRAM
         mmuModule->tableBuf[1152] = 0x48000e12;  // Some devices       in L4_PER
         mmuModule->tableBuf[1154] = 0x48200e12;  // Some other devices in L4_PER
         mmuModule->tableBuf[2048] = 0x80000e0e;  // DDR3_CODE (1st MB)
         mmuModule->tableBuf[2049] = 0x80100e0e;  //
         mmuModule->tableBuf[2050] = 0x80200e0e;  //
         mmuModule->tableBuf[2051] = 0x80300e0e;  // DDR3_CODE is RX (Read/eXecutable)
         mmuModule->tableBuf[2052] = 0x80400e0e;  //
         mmuModule->tableBuf[2053] = 0x80500e0e;  // 14 MB is the size of SPI Flash
         mmuModule->tableBuf[2054] = 0x80600e0e;  // reserved for application binary
         mmuModule->tableBuf[2055] = 0x80700e0e;  // (so, no application can be greater
         mmuModule->tableBuf[2056] = 0x80800e0e;  // than 14 MB)
         mmuModule->tableBuf[2057] = 0x80900e0e;  //
         mmuModule->tableBuf[2058] = 0x80a00e0e;  //
         mmuModule->tableBuf[2059] = 0x80b00e0e;  //
         mmuModule->tableBuf[2060] = 0x80c00e0e;  //
         mmuModule->tableBuf[2061] = 0x80d00e0e;  //
         mmuModule->tableBuf[2062] = 0x80e00e0e;  // DDR3_CODE (14th MB)
         mmuModule->tableBuf[2063] = 0x80f00e0e;  // DDR3_DATA
         mmuModule->tableBuf[2064] = 0x81000e0e;  //
         mmuModule->tableBuf[2065] = 0x81100e0e;  //
         ...
         ...                                      // DDR3_DATA is RW (256-14 = 242 MB)
         ...
         mmuModule->tableBuf[2301] = 0x8fd00e0e;  //
         mmuModule->tableBuf[2302] = 0x8fe00e0e;  //
         mmuModule->tableBuf[2303] = 0x8ff00e0e;  // DDR3_DATA
    }

    Well, you can see that all memory areas (both external SRAM and on-chip RAM and external DDR) have the same attribute 0x___00E0E, that is bufferable, cachable, not shareable and "implementation" (?).
    It seems that your recommendation for regular memory is not followed by the builder ("shareable" is not set and "not executable"is not set for memory areas I defined as RW); what about that?
    May I have problems with DMA trasfers (from SPI Flash to memory) if the target memory area is not shareable? I had to disable data caching in order to have correct results ...

    I would like to have a list of thing to be done (and to be avoided) starting with the platform descriptor and ending with writing mmu table rows of interest.

    Thank you for your time.

    Mario

     

  • 0 in reply to Mario Giovanni Casali
    TI__Mastermind 47721 points

    Hi,

    Sorry I think I made a mistake above - I actually wanted to stress on device shared as we have seen improved access latency with this setting compared to device type specifically for frequently used memory regions like PRU-ICSS memory and mixed this up with normal memory type.

    Strongly ordered: No flags are set (not buffer-able, not cache-able) : Access is not optimal

    Device: buffer-able, not cache-able : Recommended for peripheral registers

    Device Shared : buffer-able, not cache-able, shareable : Uncached shared memory for IPC

    Normal: buffer-able, cache-able : Recommended for regular memory (Choose appropriate cache policy for your application)

    So builder is doing it correctly :)

    >May I have problems with DMA transfers (from SPI Flash to memory) if the target memory area is not shareable? I had to disable data caching in order to have correct results .

    This is expected if you are doing DMA transfers to cacheable memory you need to take care of invalidate and clean manually. Refer to section 3.2 of http://infocenter.arm.com/help/topic/com.arm.doc.dai0228a/index.html for more details on this. These cache operations has its own overhead, so you might need to do some benchmarking to decide which is the best option for your application i.e DMA to uncached memory or cached memory...

  • 0 in reply to Mario Giovanni Casali
    TI__Mastermind 21645 points

    Hi Mario,

    Mario Giovanni Casali said:

    Well, you can see that all memory areas (both external SRAM and on-chip RAM and external DDR) have the same attribute 0x___00E0E, that is bufferable, cachable, not shareable and "implementation" (?).

    It seems that your recommendation for regular memory is not followed by the builder ("shareable" is not set and "not executable"is not set for memory areas I defined as RW); what about that?
    May I have problems with DMA trasfers (from SPI Flash to memory) if the target memory area is not shareable? I had to disable data caching in order to have correct results ...

    Wanted to add one point about marking memory as "shareable". You want to be careful when marking normal memory (data & code) as shareable. On Cortex-A8, I believe a memory region marked as cacheable and sharable is not held in the cache and therefore marking memory as shareable can result in a performance hit.

    Best,
    Ashish