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.

TDA4VL-Q1: Possible memory conflicts between linux dts and rtos mem maps?

Part Number: TDA4VL-Q1

HI there,

In J721 processor sdk 08_06_00_11 rtos vision_apps, the mem map for C7x_1 as L3 MEM is defined and used as:

/* MSMC for C7x_1 [ size  3.78 MB ] */
#define MSMC_C7x_1_ADDR (0x70020000u)
#define MSMC_C7x_1_SIZE (0x003C8000u)

in vision_apps/platform/j721s2/rtos/app_mem_map.h.

This occupies almost the entire MSMC ram.

However, in linux dts file /ti-processor-sdk-linux-j721s2-evm-08_06_00_10/board-support/linux-5.10.162+gitAUTOINC+76b3e88d56-g76b3e88d56/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi, the MSMC is partitioned as

msmc_ram: sram@70000000 {
       ......
        atf-sram@0 {
            reg = <0x0 0x20000>;
        };

        vpu_sram: vpu-sram@20000 {
            reg = <0x20000 0x1f800>;
        };
       .......
   
And vpu_sram is referenced in  vpu: video-codec@4210000 as
sram = <&vpu_sram>;
Apparently the addresses used by rtos demos and vpu are overlapped. Will this lead to problems while both vpu and vision apps are running? Thanks!
  • Any experts can help with this? Thanks!

  • Hi,

    This seems to be an issue. Let me confirm the same internally. I have raised a JIRA ticket for the same internally. Placing the JIRA ticket here for TI's internal reference.

    https://jira.itg.ti.com/browse/ADASVISION-5826

    Meanwhile, could you please let me know if you have a usecase where you would be using codec and deep learning on C7x (which mostly uses MSMC)?

    Regards,
    Nikhil

  • Thanks Nikhil. I plan to build an ADAS demo following the related contents in RTOS SDK and LINUX SDK. The codec and openvx on C7X are both needed. It would be nice if we can fix some bugs in advance. Since I cannot access the JIRA website you mentioned, could you please let me know if there is a repsonse? Thanks!

  • Hi,

    I raised this internally and please find the update below.

    The carveout is being made in the expectation of codec to use it. But there is only a check in the driver for the carveout of specific size, but Codec is not allocating any memory.

    The MSMC memory on AEP is fully getting utilized by RTOS understood from the system memory map.  So, there won’t be any issue running Codec with TIDL Demos.

    Regards,

    Nikhil 

  • Hi NIkhil, do you mean that in all the use cases of the vpu codec, the sram carveout  will not be used? 

    And what about the other two overlapped areas:

            tifs-sram@1f0000 {
                reg = <0x1f0000 0x10000>;
            };

            l3cache-sram@200000 {
                reg = <0x200000 0x200000>;
            };
    For example, is this 'tifs-sram' related to the tifs firmware in SMS and reserved for the M4F core in wakeup domain? Will this be conflict with memmap defined in  RTOS vision_apps/platform/j721s2/rtos/app_mem_map.h? Since  the memmap definition for RTOS  is only used by firmwares running on R5F's and C71's, TIFS on M4F will not know the memory overlap if TIFS uses this  tifs-sram area.
    Thanks!
  • Hi,

    do you mean that in all the use cases of the vpu codec, the sram carveout  will not be used? 

    Yes.

    I believe the TIFS would use the region specified in the RTOS region (i.e., 0x703F0000 to 0x703FFFFF)

    I think the memory mapping on the Linux side looks like a bug for the MSMC ti_fs region. I have raised another ticket for this issue. Placing the JIRA ticket here for TI's internal reference.

    https://jira.itg.ti.com/browse/LCPD-34201

    I shall get back to you once I receive an update on this thread

    Regards,

    Nikhil

  • Hi Nikhil, do you mean the region specified in for example: pdk_j721s2_08_06_00_31/packages/ti/drv/ipc/examples/common/j721s2/linker_r5f_mcu1_0.lds:91 MSMC3_DMSC_FW  (RWIX)   : origin=0x703F0000 length=0x10000         /* 64KB */ ?

    However, I found another weird thing. In mcusw/build/j721s2/mcu1_0/linker_r5.lds:68, the region is defined as 

    MSMC3_DMSC_FW  (RWIX)   : origin=0x704F0000 length=0x10000         /* 64KB */ .

    In mcusw/build/j721s2/mcu2_1/linker_r5.lds:62, the region is defined as

    MSMC3_DMSC_FW  (RWIX)   : origin=0x707F0000 length=0x10000         /* 64KB */

    And there are many other places in rtos sdk that the region is defined as 0x707F0000. Are all these mistakes? These addresses have all exceeded the MSMC size. Where can we find an accurate region definition? Thanks! 

  • Hi,

    It should be at the end of the MSMC region which is 0x703F0000 64kb as mentioned in the RTOS memory map, as the cache is disabled.

    However, I found another weird thing. In mcusw/build/j721s2/mcu1_0/linker_r5.lds:68, the region is defined as 

    MSMC3_DMSC_FW  (RWIX)   : origin=0x704F0000 length=0x10000         /* 64KB */ .

    In mcusw/build/j721s2/mcu2_1/linker_r5.lds:62, the region is defined as

    MSMC3_DMSC_FW  (RWIX)   : origin=0x707F0000 length=0x10000         /* 64KB */

    And there are many other places in rtos sdk that the region is defined as 0x707F0000. Are all these mistakes?

    I think these are mistakes. Also it doesn't matter in these cases as these applications are not using the DMSC.

    https://jira.itg.ti.com/browse/ADASVISION-5826

    Regarding the changes on the Linux end, the node is being removed and the changed logic has been taken care. This should be available in the upcoming release.

    Regards,

    Nikhil