• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 429 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

J784S4XEVM: Should I flash and re-partition SD card again if I want to change msmc L3 cache settings in 'board-cfg.c' file in the Linux SDK?

Sai Srikar Palukuru
Prodigy 60 points
Part Number: J784S4XEVM
Other Parts Discussed in Thread: TDA4VH

Hello,

I want to test TDA4VH on J784S4 EVM with different L3 MSMC Cache size settings. Each time, is there a better way than flashing the whole Linux SDK on to the SD Card after changing the cache size in 'board-cfg.c' file?

Thanks

Sai

  • 0
    TI__Guru**** 155350 points

    Hi Sai,

    This is part of TIFS so you rebuild the tiboot3.bin by using make u-boot command and copy the tiboot3.bin that gets created under $PSDK_Linux/board-support/k3-image-gen to the BOOT partition of the SD card. That should be enough.

    - Keerthy

  • 0 in reply to Keerthy J
    Prodigy 60 points

    Is this the right place to find how to rebuild tiboot3.bin? 3.1.1.1. General Information — Processor SDK AM62Ax Documentation

    Else, please direct me to the one for my EVM (J784S4  Linux SDK)

  • 0 in reply to Sai Srikar Palukuru
    Prodigy 60 points

    I was able to generate tiboot3.bin file by using 'make u-boot' command. Although you mentioned it above, it wasn't clear if you were providing a command for me or were suggesting a process. I assumed its a process, so was digging into documentation to outline the steps. However, thanks for giving the command to me. At first, I had an issue running it, since the default compiler this make command was using had some version/library issues. I replaced it with the compiler version suggested in the SDK documentation and it worked.

    Moved the tiboot3.bin file into SD card. Is there a way to verify my changes have applied using k3conf tool or some other way? It is important for us to verify if the MSMC cache settings have bee update. Please let me know.

    Thanks
    Sai

  • 0 in reply to Sai Srikar Palukuru
    TI__Guru**** 155350 points

    Hi Sai,

    What's the l3 cache size that you have configured? We can easily cross verify the same in U-Boot prompt.

    Try 'md address'

    Address you can start with 0x70000000.

    Since the cache grows downwards you can easily cross check that the higher Mega bytes that you configure as l3 cache are inaccessible. If your L3 cache size is 0 then the entire msmc size will be accessible from u-boot.

    Best Regards,

    Keerthy

  • 0 in reply to Keerthy J
    Prodigy 60 points

    Thanks, but apologies - can you let me know how to access u-boot prompt. I have not done that before. Is it something I run from a certain directory in the EVM?

  • 0 in reply to Sai Srikar Palukuru
    TI__Guru**** 155350 points

    Hi Sai,

    How are you booting to Linux on J784s4? Are you booting to Linux or QNX? What is the bootloader in use?

    - Keerthy

  • 0 in reply to Sai Srikar Palukuru
    TI__Guru**** 155350 points

    Hi Sai,

    While booting to Linux. Press any key before U-boot.

    See below logs:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    U-Boot SPL 2021.01-g62a9e51344 (Mar 13 2023 - 15:43:18 +0000)
    ti_i2c_eeprom_am6_get: Ignoring record id 255
    ti_i2c_eeprom_am6_get: Ignoring record id 255
    ti_i2c_eeprom_am6_get: Ignoring record id 255
    ti_i2c_eeprom_am6_get: Ignoring record id 255
    ti_i2c_eeprom_am6_get: Ignoring record id 255
    ti_i2c_eeprom_am6_get: Ignoring record id 255
    ti_i2c_eeprom_am6_get: Ignoring record id 255
    ti_i2c_eeprom_am6_get: Ignoring record id 255
    ti_i2c_eeprom_am6_get: Ignoring record id 255
    ti_i2c_eeprom_am6_get: Ignoring record id 255
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.3--v08.06.03 (Chill Capybar')
    SPL initial stack usage: 13472 bytes
    Trying to boot from MMC2
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
    Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.8(release):v2.8-226-g2fcd408bb3-dirty
    NOTICE: BL31: Built : 15:42:56, Mar 13 2023
    I/TC:
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Hit any key to stop autoboot:  0


    This will get you to U-boot prompt.

    - Keerthy

  • 0 in reply to Keerthy J
    Prodigy 60 points

    Thanks Keerthy. Upon trying md 0x70000000, I am seeing the following results. I have setup my MSMC L3 cache as 7MB

    Seems like I am able to read the memory from this address.

     Upon trying md 0x70100000, md 0x70200000, md 0x70300000 - these addresses are un-readable as below

    Any address on or beyond 0x70400000 results in an error as below

    -Sai

  • 0 in reply to Sai Srikar Palukuru
    TI__Guru**** 155350 points

    Hi Sai,

    This is from the device TRM. The total MSMC SRAM memory available is 8MB.

    Sai Srikar Palukuru said:

    Thanks Keerthy. Upon trying md 0x70000000, I am seeing the following results. I have setup my MSMC L3 cache as 7MB

    You see non-zero content as ATF(ARM trusted firmware) resides there.

    Sai Srikar Palukuru said:

     Upon trying md 0x70100000, md 0x70200000, md 0x70300000 - these addresses are un-readable as below

    You are able to read 0s as they are indeed 0s.

    Sai Srikar Palukuru said:

    Any address on or beyond 0x70400000 results in an error as below

    If you have configured 4MB as cache the above will be observed.

    Can you share the code change you did to allocate 1MB of L3 cache from the SRAM?

    Note: I edited for TDa4VH config.

    - Keerthy

  • 0 in reply to Keerthy J
    Prodigy 60 points

    Keerthy, if you are referring to this block diagram from an online version of TRM on TDAV4H, something is wrong with this picture. 

    1. MSMC SRAM for TDA4VH in my understanding is supposed to be 8MB

    2. The number of Arm A72 cores must be a total of 8. Versus just 2 shown in this picture. Plus a lot more things are off between the picture and the technical specifications in my opinion. 

    I was asked to refer to the following discussion to adjust my MSMC cache settings. - https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1199941/dra829v-msmc-region-as-l3-cache-for-a72-core/4524353#4524353 by Jelena

    Here are the changes I made to the board_cfg.c file in my Linux SDK(May 2023):


    ```
    /* boardcfg_msmc */
    .msmc = {
    .subhdr = {
    .magic = BOARDCFG_MSMC_MAGIC_NUM,
    .size = sizeof(struct boardcfg_msmc),
    },
    .msmc_cache_size = 0x10,
    },

    ```

    I have used three different settings:
    0x8 for 2MB
    0x10 for 4 MB and
    0x1C for 7MB
    With these settings, I have seen the memory performance increase linearly. I have not tried anything beyond 7MB though. But my memory access screenshots using u-boot prompt is something that I am unable to wrap my head around. 
  • 0 in reply to Sai Srikar Palukuru
    TI__Guru**** 155350 points

    Hi Sai,

    I have tried changing the msmc_cache_size parameter under the soc/j784s4/evm/board-cfg.c.

    The pattern is:

    0x8 = 1MB
    0x10 = 2MB
    0x18 = 3MB
    0x20 = 0x4M

    ....

    0x38 = 7MB

    Recommend NOT to use 8Mb as l3 cache as we need SRAM for ATF & TIFS data.

    Ex: 0x0

    devmem2 0x70100000 w
    /dev/mem opened.
    Memory mapped at address 0xffffbee43000.
    Read at address 0x70100000 (0xffffbee43000): 0x00000000
    root@j784s4-evm:~# devmem2 0x70600000 w
    /dev/mem opened.
    Memory mapped at address 0xffff93297000.
    Read at address 0x70600000 (0xffff93297000): 0x00000000
    root@j784s4-evm:~# devmem2 0x70700000 w
    /dev/mem opened.
    Memory mapped at address 0xffff8b47d000.
    Read at address 0x70700000 (0xffff8b47d000): 0x00000000

    0x8 (default)

    root@j784s4-evm:~# devmem2 0x70000000
    /dev/mem opened.
    Memory mapped at address 0xffffa9999000.
    Read at address 0x70000000 (0xffffa9999000): 0xAA0003F4
    root@j784s4-evm:~# devmem2 0x70100000
    /dev/mem opened.
    Memory mapped at address 0xffffab220000.
    Read at address 0x70100000 (0xffffab220000): 0x00000000
    root@j784s4-evm:~# devmem2 0x70200000
    /dev/mem opened.
    Memory mapped at address 0xffff9c687000.
    Read at address 0x70200000 (0xffff9c687000): 0x00000000
    root@j784s4-evm:~# devmem2 0x70300000
    /dev/mem opened.
    Memory mapped at address 0xffffa7353000.
    Read at address 0x70300000 (0xffffa7353000): 0x00000000
    root@j784s4-evm:~# devmem2 0x70400000
    /dev/mem opened.
    Memory mapped at address 0xffff921f1000.
    Read at address 0x70400000 (0xffff921f1000): 0x00000000
    root@j784s4-evm:~# devmem2 0x70500000
    /dev/mem opened.
    Memory mapped at address 0xffffa5c62000.
    Read at address 0x70500000 (0xffffa5c62000): 0x00000000
    root@j784s4-evm:~# devmem2 0x70600000
    /dev/mem opened.
    Memory mapped at address 0xffff9e2ca000.
    Read at address 0x70600000 (0xffff9e2ca000): 0x00000000
    root@j784s4-evm:~# devmem2 0x70700000
    /dev/mem opened.

    ERROR: Unhandled External Abort received on 0x80000001 from S-EL1
    ERROR: exception reason=0 syndrome=0xbf000000

    0x10

    root@j784s4-evm:~# devmem2 0x70400000
    /dev/mem opened.
    Memory mapped at address 0xffff8af32000.
    Read at address 0x70400000 (0xffff8af32000): 0x00000000
    root@j784s4-evm:~# devmem2 0x70500000
    /dev/mem opened.
    Memory mapped at address 0xffff8b933000.
    Read at address 0x70500000 (0xffff8b933000): 0x00000000
    root@j784s4-evm:~# devmem2 0x70600000
    /dev/mem opened.

    ERROR: Unhandled External Abort received on 0x80000000 from S-EL1
    ERROR: exception reason=0 syndrome=0xbf000000
    Unhandled Exception from EL0

    Best Regards,
    Keerthy

  • +1 in reply to Keerthy J
    Prodigy 60 points

    Thanks for generating the pattern. I will have to adjust my test settings to reflect these changes again. Appreciate the help.