• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 4 answers
  • Subscribers 98 subscribers
  • Views 533 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.

Original question:

Linux/TDA2SX: I,m getting kernel panic if I modified mem=2048M in uenv.txt

Linux/TDA2SX: Regarding ,Increase the size of SR-1 region(cached)

Alapati kavyaharini
Expert 1080 points
Part Number: TDA2SX

Tool/software: Linux

Hi all,

I am presently  working on TI EVM TDA2x board with cpu as "DRA752-GP ES2.0" & DRAM = 4GB.

https://e2e.ti.com/support/processors/f/791/p/813005/3020155#3020155

In the above discussion present in the link, my query was to increase the size of SR1 region because my system use-case requirements demands more.
Infact I have my custom board designed with 4GB DDR3.
So my intention is to increase the current size of 250MB of SR-1 region to 1GB (cached SR-1 region).
Can you please tell me how to do this in the memory map.


Btw, please don't suggest to decrease my consumption of SR-1 to fit within 250MB or 512MB, because neither usecases can be dropped to do that nor any optimization is possible to fit within the default size of 250/512MB.
Hope you understand the point. Expecting your suggestions in this regard..

Thanks & Regards,

A.Kavya Harini.

  • 0
    TI__Genius 14650 points

    Hi Kavya,

    IPU AMMU has limited entries which are used to cover regions in the SoC. The AMMU has 4 large page tables each of which can cover 512MB each.

    Large-Page[0] covers 512MB between 0x40000000 -- 0x60000000. This region corresponds to the device registers many of which are accessed by M4 as part of its initialization.

    Large-Page[1] covers 512MB between 0x60000000 -- 0x80000000. This region corresponds to more device registers and timers used by IPU. This region also maps to tiler address space which is used for multimedia use-cases.

    Large-Page[2] covers 512MB between 0x80000000 -- 0xA0000000. This region corresponds to DDR. Its marked as cached

    Large-Page[3] covers 512MB between 0xA0000000 -- 0xC0000000. This region corresponds to DDR. Its marked as non-cached as atleast 1MB is needed for Inter-processor communication (can't use medium pages as they only correspond to 32KB each).

    Due to this limitation, you can at max use 512MB of cached memory. This also is further restricted by the fact that when running in parallel with kernel, kernel will require some-space for its pages. Due to this, the maximum size for a carveout for SR usage is ~330MB.

    Regards

    Shravan

  • 0 in reply to Shravan Karthik
    Expert 1080 points

    Hi Shravan,

    Thanks for the reply.

    IPU AMMU has limited entries...............

    If number of entries are limited in AMMU, then atleast  can we increase the size of each entry beyond 512MB, so that I can address larger space for SR1.?

    Btw,  If SR1 is limited and capped to 330MB (cached), Can anyone really use TDA2Sx to its full capacity (4EVEs, 2DSPs, IVA and 2A15) for running the feature rich use-cases in Automotive. (which is my current requirement). ??

    Can you please rethink and give me suggestion ?

    But If  you still repeat,  it is  THE limitation and nothing can be done, then TDA2SX seems like a flawed architecture to me, where capacity is present but it can't be used.

    I'm also wondering  What is the use of 4GB address capacity of the SoC when SR-1 can't  be increased for data crunching ?

    We selected this SoC based on its highest processing performance but it is  turning out that it is bogged by a trivial reason of limited cached-region. Is this justified?

    Thanks & Regards,

    A.Kavya Harini.

  • 0 in reply to Alapati kavyaharini
    Expert 1080 points

    Hi shravan,

    I am waiting for your response.

    Thanks and regards,

    A.kavya harini

  • 0 in reply to Alapati kavyaharini
    TI__Genius 14650 points

    Hi Kavya,

    Vision-SDK in its current form can't support access to DDR regions > 1GB for IPU. It is a known limitation.

    If you don't intend to have CPU accesses from M4, you could potentially have links writing to buffers from higher address ranges in DDR (>1GB but <2GB). However, this will require:

    1. A custom allocator (running on BIOS, but doesn't use standard BIOS APIs like malloc etc), which does pointer manipulation. Current BIOS APIs does heap management which requires IPU to have access to the physical addresses.

    2. Manipulation of links to write to direct pointers rather than IPU allocated buffers.

    3. Cache management from A15 for custom allocator (similar to what the memcache module on VSDK does).

    These require solutions which aren't supported in the SDK. It is for this reason, we recommend using DDR <=1GB for chains involving the IPU.

    We do have support for >1GB DDR access for DSP, GPU and A15 (LPAE in Linux, can even provide access for DDR regions >2GB).

    Regards

    Shravan 

  • 0 in reply to Shravan Karthik
    Expert 1080 points

    Hi Shravan,

    Thanks for your reply.

    ===>Vision-SDK in its current form can't support access to DDR regions > 1GB for IPU. It is a known limitation.

             In Vision-SDK, whether I can expect this support for upcoming versions.

    ===>LPAE in Linux, can even provide access for DDR regions >2GB

             Could you please tell me, How to access the 40-bit addresses in my code, which is >2GB in Linux A15?

    Thanks & Regards,

    A.Kavya Harini.

  • 0 in reply to Alapati kavyaharini
    TI__Genius 14650 points

    Hi Kavya,

    1. Yes, we will have some reference code indicating how this can be achieved as part of the next release (scheduled end of this month).

    2. With LPAE enabled, kernel manages the ARM MMU to access >32 bit PA, while using a 32 bit VA.In kernel you could ioremap physical address > 32bit, and still receive a valid VA. 

    Regards

    Shravan

  • 0 in reply to Shravan Karthik
    Expert 1080 points

    Hi Shravan,

    Thanks for the reply.we will check it(SR-1 region) in the next release.

    I have a small doubt,could you please clarify me.I want to access the >2GB from user space With LPAE enabled in kernel.Can I use "mmap" for accessing the > 32 bit addresses  in linux from user space?

    Thanks & Regards,

    A.Kavya Harini.

  • 0 in reply to Alapati kavyaharini
    TI__Genius 14650 points

    Hi Kavya,

    It should work, however, I'm not sure if the mmap call allows a pointer greater than 32bit, you would have to check.

    The physical address for higher order mem is in the range 0x200000000 to 0x27FFFFFFF. 

    Regards

    Shravan