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.

MSM Segmentation



Hi All,

 Is it possible to create 2 segments in MSM : 1 with 64kB(with Physical address) and other with 1,984kB(Virtual address)? I am asking this question since 1984kB is not power of 2. For section of 1984kB, I require cache to be enabled, and for 64kB needs to be cache disabled in my code. The reason for this doubt is the following statement given in SPRUGW7A(MSMC Controller)

"Segments are always sized to a power of two and start on a corresponding power-of-two boundary (for example, a 4 KB segment always starts on a 4 K boundary, and a 4 GB segment corresponds to the entire 32-bit address space). For the SMS port MPAX unit, the maximum allowed segment size is 16 MB (SEGSZ=10111b), which would cover the full MSMC storage space."

By this statement, I understand that if cache disabling using MPAX has the above requirement of power of 2 boundary and size. If MSM segments are used with physical addressing, this requirement is not valid. Is my understanding correct?

Please clarify my doubt.

Regards,

Sandeep M

  • Hi Sandeep,

    Regarding the "power of 2" problem, please refer the section "7.3.2.1.1 Matching Multiple Segments" of SPRUGW0C (http://www.ti.com/lit/pdf/sprugw0).  It says "Higher numbered segments take precedence over lower numbered segments."  You should define the small segment to take precedence.

    Regarding the MAR (cacheable or not cacheable) for C66, my understanding is a region size is always 16MB.  We cannot define 64KB region by MAR.

    One possibility is, we access the 64KB segment and 1984KB segment by different way.  Please refer SPRY150A (http://www.ti.com/litv/pdf/spry150a).  We can access MSM as SL2 or SL3. To my best knowledge, we have different MAR regions for SL2 and SL3.  (I remember SL2 is always cacheable even though SL3 can be configurable.)

    Regards,
    Atsushi