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.

TDA4VM: Load example binary on R5 main core, via U-boot on A72

Part Number: TDA4VM

Building the udma_baremetal_memcpy_testapp from the RTOS SDK, I've tried to load it onto the MCU2_0 core by performing the following (boot via SD-card):

Hit any key to stop autoboot: 0
=> rproc init
=> fatload mmc 1 0x80000000 /anton/memcpy_test_for_t3_mcu2_0_release.xer5f
2540972 bytes read in 66 ms (36.7 MiB/s)
=> rproc load 4 0x80000000 2540972
Load Remote Processor 4 with data@addr=0x80000000 39061874 bytes: Success!
=> rproc start 4


I then open CCS to verify that the application is running, but I only see that the ATCM area (0x00000000--0x00007FFF) is empty:


To my understanding, when loading from u-boot, the ATCM is enabled per default and that the application needs to have its reset vectors in ATCM.
I see that the .map file for the binary I've built does not use this area.
Is there an example of how to set up the linker file, to add the reset vectors into ATCM area?

Here is how I built the binary from the PDK/build folder:
make udma_baremetal_memcpy_testapp CORE=mcu2_0 -sj

  • Hi,

    Can you check below FAQ?

    e2e.ti.com/.../989328

    Regards,

    Brijesh

  • Yes, I built the same application using the description in the FAQ you linked, some questions from my side:
    In the .map file for dss_display_testapp_mcu2_0_release.xer5f I can still see that TCMA section is not used
    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    R5F_TCMA_SBL_RSVD 00000000 00000100 00000000 00000100 X

    There is however some utilsCopyVecsToAtcm section allocated.

    Furthermore, in the patch file attached to that thread, there are some parts which are of interest, for example:
    +/* linker options */
    +--fill_value=0
    +--stack_size=0x2000
    +--heap_size=0x1000
    +
    +-e __VECS_ENTRY_POINT
    +--retain="*(.utilsCopyVecsToAtcm)"

    And

    +{
    + .vecs : {
    + __VECS_ENTRY_POINT = .;
    + } palign(8) > R5F_TCMA0

    I think it's the linker file patches which are of interest for me, should I try to apply similar patches to my linker file?

  • Hi,

    Yes, please follow this patch and apply similar changes in your linker file. 

    You are correct, PDK examples does not use TCM memories, they use OCM memory and as part of init, they copy boot vectors from OCM memory to TCM memory (or whatever mapped at offset0). 

    Regards,

    Brijesh

  • Hi,

    Thanks for providing link to the patch, I adapted the linker file to include TCMA and its corresponding section, in addition to modifying our startup code to be within this region.

    One question: the patch file contains the following MEMORY sections:
    +    R5F_TCMA0(RWIX)             : ORIGIN = 0x100 , LENGTH = 0x00008000 - 0x100
    +    /*R5F_TCMA_SBL_RSVD(X): ORIGIN = 0x00000000 , LENGTH = 0x100*/
    Which conforms with the Jacinto 7 SBL documentation, where 0x00000000--0x00000100 is reserved for the R5 SBL: https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/07_00_00_11/exports/docs/pdk_jacinto_07_00_00/docs/userguide/boot/boot_jacinto.html

    However, from the J721E Technical reference manual, section 6.3.3.11 R5FSS Boot Options, it is stated that:
    "Load the desired code into the TCM via the TCM slave port
    a. Exception vectors should be located at address 0x00000000 of the TCM"

    Indeed, when trying to put my reset vectors into address 0x00000000, it looks like the application starts and executes.
    Could you elaborate a little bit on this?

    Thanks,
    Anton Annenkov

  • Hi Anton,

    This area is reserved only for MCU R5F, for the other R5F, I really don't think any issue in using this area, ie first 256 bytes.

    Regards,

    Brijesh