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: The materials for boot configuration

Part Number: TDA4VM

Hi

The boot vector is stated to be stored in PSRAM1KECC. However, there is no one with the same name on the memory map as shown below. Based on the size of the area, am I correct in assuming that it is identical to PSRAMECC?

 

Is there any document or sample that shows what kind of program or data structure should be placed in PSRAM?

  • Hi HaTa,

    I will investigate this and come back to you.

    Regards

    Karthik

  • I need your reply soon.

  • HaTa,


    What document is this and who provided you this document?


    Regards,
    Shyam

  • Hi Shyam

    Referring to TRM.

  • Hi

    Please update your status for this thread?

  • Do you have any update?

  • Hello HaTa,

    I have confirmed with our design team that PSRAMECC0 is the same as PSRAM1KECC.

    Regards,

    Kyle

  • Hi Kyle

    How about the below?

    >Is there any document or sample that shows what kind of program or data structure should be placed in PSRAM?

    Currently, there is no good document to know how to prepare the boot program.

    Therefore, cannot boot the code without CCS.

    Thanks and Best regards,

    HaTa

  • HaTa,

    When you say boot without CCS, can you please confirm which scenario is being attempted?

    1. Booting C7x core with Linux on A72.
    2. Booting C7x core with SBL loading the firmware on the C7x.

    Please also capture the other details that the customer is requesting for and provide details.

  • Hi

    According to TRM chapter 6.5.3.7,

       "6.5.3.7 C71x DSP Boot Configuration
       In this device, the C71x boots from system memory instead of booting from ROM. A 1KB boot RAM
       (PSRAM1KECC) is used to store boot vectors for the C71x CPU."

    But, that is all description to "C7x DSP Boot configuration".

    There is no other comment for it.

    What I'd like to know is

       - The boot mechanism of  "the C71x boots from system memory instead of booting from ROM" which is described at ch6.5.3.7

       - What is "boot vectors for the C7x CPU" which is described at ch6.5.3.7

    Thanks and Best regards,

    HaTa

  • Hi

    Thanks to getting the information how to prepare the boot image from Karan, customer can resume their verification now.

    Thank you very much.

    So, while preparing it, they faces to the issue.

    When the image is expanded to DSP-L2 by SBL, it freezes.

     

    ■Evidence

    (1) DSP program and app

    For the purpose of clarifying the problem, we prepared two cases.

     

    Case (WithL2): DSP code that uses L2

    DSP_WithL2.zip

    Case (WithoutL2): DSP code that does not use L2 at all

    DSP_WithoutL2.zip

     

     

     

    In the above two cases, only the memory map has been changed.

     

     

    (2) App generation batch

    The app in the zip is generated by the following batch

    The images of mcu1_0, mcu1_1, mcu2_0, mcu2_1, mpu1_0, mpu1_1, and c7x (out of (1)) are put together.

    (The paths are different depending on your environment, so you may need to update some of them to use them)

    MakeApp.zip

    (3) Boot loader

    You can see that even if you use the standard boot loader, it stops in the middle

    However, the logs are insufficient, so I made the following changes to the makefile and built it

    SBL_LOG_LEVEL=3

    tiboot3.zip

    ■Execution procedure

    App

    (in evidence 1)

    tiboot3.bin

    (in evidence (3))

    tifs.bin

    (in PDK)

    Put them into the SD card and set EVM to SD boot.

    Connect to MCU-UART via USB and check the output log after power-on

     

     

    Results

    Case (WithL2): DSP code that uses L2

    UART_WithL2.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    SBL Revision: 01.00.10.00 (Apr 27 2021 - 11:14:00)
    TIFS ver: 21.1.1--v2021.01a (Terrific Lla
    SCISERVER Board Configuration header population... PASSED
    Sciclient_setBoardConfigHeader... PASSED
    Efuse xlated: VD 2 to 800 mV (OppVid: 0x37, Slave:0x48, Res:0x0)
    Successfully set voltage to 800 mV for Slave:0x48, Res:0x0
    Initlialzing PLLs ...done.
    InitlialzingClocks ...done.
    Initlialzing DDR ...done.
    Initializing GTC ...Begin parsing user application
    Calling Sciclient_procBootRequestProcessor, ProcId 0x20...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x21...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x1...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x2...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x6...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x7...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x8...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x9...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x3...
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    If you connect with CCS after this, the DSP is not able to boot correctly.

     

    Case (WithoutL2): DSP code that does not use L2 at all

    UART_WithoutL2.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    SBL Revision: 01.00.10.00 (Apr 27 2021 - 11:14:00)
    TIFS ver: 21.1.1--v2021.01a (Terrific Lla
    SCISERVER Board Configuration header population... PASSED
    Sciclient_setBoardConfigHeader... PASSED
    Efuse xlated: VD 2 to 800 mV (OppVid: 0x37, Slave:0x48, Res:0x0)
    Successfully set voltage to 800 mV for Slave:0x48, Res:0x0
    Initlialzing PLLs ...done.
    InitlialzingClocks ...done.
    Initlialzing DDR ...done.
    Initializing GTC ...Begin parsing user application
    Calling Sciclient_procBootRequestProcessor, ProcId 0x20...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x21...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x1...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x2...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x6...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x7...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x8...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x9...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x3...
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    If you connect with CCS after this, the DSP is able to boot correctly.

     

    From the log, we can see that it is freezing when writing from SBL to 0x64800000 (DSP-L2).

     

     

    Environment

    ・SDK

    PROCESSOR-SDK-RTOS-J721E_07.02.00.06

     

    We have confirmed that the same problem occurs with the SBLs of the following SDKs.

    07.03.00.07

    07.01.00.11

     

     

    ・CCS settings

    Thanks and Best regards,

    Tsurumoto.

  • C7x MMU must be programmed (secure supervisor or non-secure supervisor mode or both) before writing to L1, L2 or L3 memories. If this is not programmed at the right privilege level then it will result in a page fault. 

    Regards,
    Shyam

  • Hi Shyam

    Confirmed that writing CPU to L2 causes freezing.

    They can memcpy to MSMC. However, copying to L2 does not pass.

  • Hi Tsurumoto-san,

    Thanks for confirming with the experiment. Some updates

    1. The hardware designers feel that there should be no issue writing to C7x L2 but there could be firewalls in place between R5F and C7X DSP which is preventing write access. I need to check if we can disable the firewalls and test the same memcpy program to see if the write goes through. 

    2. If we use OSPI boot mode then all sections of the image is transferred via DMA only. For MMCSD boot there are CPU copies involved. We are still checking how to force a DMA transfer. There could be some restrictions in forcing the ADMA in MMCSD IP due to alignment and size considerations. 

    Regards,
    Shyam

  • Hi Shyam

    Please update your progress for it for now?

  • Tsurumoto-san, 

    As discussed today, we have made progress and we need a little more time to share with you a package that you can try.

    I will post the next update when ready. No further action on you for now.

    Regards

    Karthik

  • Tsurumoto-san,

    I found a duplicate thread for this, lets continue discussions on this here. Closing this one.

    Regards

    Karthik