TDA4VE-Q1: Baremetal LPDDR4 RAM testing

Hi,

Andreas K said:

Is there an example of a bare metal application for accessing the DDR RAM?

The short answer is no. 

Accessing the DDR memory is performed directly by accessing the DDR memory address region of the TDA4 device (ex: write to address 0x80000000 and read it back). 

Andreas K said:

We saw that the board initialization via GEL scripts performs a lot of steps before being able to initialize the LPDDR4 RAM.
An example Cortex-R5 bootloader that does the hardware initialization would be very helpful.

TI provides bootloader code through the Software Development Kits (SDKs). See for example the tiboot3.bin file which includes the R5 bootloader code to initialize DDR.

https://www.ti.com/tool/PROCESSOR-SDK-J721S2 

https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j721s2/10_00_00_08/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html#boot-flow 

Regards,
Kevin

Hi Kevin,

thanks for your reply. Our usecase is to transfer bootloader code into the OCM RAM of the Cortex-R5 and run it. Currently we had issues to finish the board initialization. This failed with the keywriter_img and flash_programming image (UNIFLASH Tool).

We know about the High-Level documentation, but we are missing details here, why the initialization does not finish (see my other tickets). It would be very helpful to have a step-by-step guide on how to compile a baremetal R5 application that does the board startup.

Best regards,

Andreas

Hi Andreas,

Andreas K said:

Currently we had issues to finish the board initialization. This failed with the keywriter_img and flash_programming image (UNIFLASH Tool).

If these comments are related to the original E2E below, let's please keep discussing the issue in the original E2E thread. Unfortunately, I am not the right TI employee to assist you with UNIFLASH.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1410769/sk-tda4vm-uniflash-tool-boot-into-u-boot-cannot-transfer-tiboot3-bin 

Regards,
Kevin

Hi Kevin,

in that case I want to stay within the provided SDK boot code provided by
ti-processor-sdk-rtos-j721e-evm-10_00_00_05/pdk_jacinto_10_00_00_27 in packages/ti/boot/sbl

Running make help in packages/ti/build shows me that there are many sbl targets for mmcsd, ospi, uart as well as hs variants. For the SK-TDA4VM evaluation board I want to try running the sbl_uart_img via the XDS200 TI Debugger and Code Composer Studio 12.4:

1. make BOARD=j721e_evm CORE=mcu1_0 all (required due to missing dependencies)

2. make BOARD=j721e_evm CORE=mcu1_0 sbl_uart_img

3. Bare metal debugging with CCS12.4
   
   1. Launch Selected configuration for J721E_EVM (which was created as described in ccs debug setup)
   2. Run in the JS window: loadJSFile("/home/dev/ti/ti-processor-sdk-rtos-j721e-evm-10_00_00_05/pdk_jacinto_10_00_00_27/packages/ti/drv/sciclient/tools/ccsLoadDmsc/j721e/launch.js")
   3. This initializes the board via external tool (that is what we want to be done by the Cortex-R5)
   4. Connect MCU_Cortex_R5_0 > Load Code > /home/dev/ti/ti-processor-sdk-rtos-j721e-evm-10_00_00_05/pdk_jacinto_10_00_00_27/packages/ti/boot/sbl/binary/j721e_evm/uart/bin/sbl_uart_img_mcu1_0_relase.xer5f
   5. Debugging is not possible. ELF is not run and there is no error, core is stuck at address 0x000004CA
4. Do the same with the sbl_boot_test
   1. Run launch.js
   2. Connect MCU_Cortex_R5_0 > Load Code > /home/dev/ti/ti-processor-sdk-rtos-j721e-evm-10_00_00_05/pdk_jacinto_10_00_00_27/packages/ti/boot/sbl/example/k3MulticoreApp/binary/j721e/sbl_boot_test_j721e_evm_mcu1_0TestApp_release.xer5f
   3. ELF gets stuck in the HwiP_undefined_handler_c()
5. Another example with the keywriter_img
   1. Launch selected configuration for J721E_EVM in CCS
   2. Do not run launch.js
   3. Connect to MCU1_0
   4. Load packages/ti/boot/keywriter/binary/keywriter_img_j721e_release.xer5f
   5. Debugger starts in main()
   6. Program fails in function UART_printf(). I think this is expected, as the function requires TISCI to be running (is this correct?)

I am missing any starting point to correctly run the baremetal board initialization, so that we can adjust the code to run DDR tests.

Regards,

Andreas

Hi Kevin,

an addendum: apparently there is also a timing issue.

I can run the Cortex-R5 ELF packages/ti/boot/sbl/binary/j721e_evm/emmc_boot0/bin/sbl_emmc_boot0_img_mcu1_0_release.xer5f
when I connect and load the ELF to MCU1_0 directly after a reset.

Inside the sbl_main.c I can see that we can enable the DDR initialization with -DSBL_ENABLE_DDR, but the program fails at loading the SYSFW with SBLSciClientInit(devGroup), I guess due to the SBL being unable to read the sysfw image from emmc0, as it is currently empty.
Also the SBL_log() output via UART1 cannot be deciphered. Is the baudrate configured to another value than 115200?

Regards,

Andreas

Hi Andreas ,

Andreas K said:

packages/ti/boot/sbl/binary/j721e_evm/emmc_boot0/bin/sbl_emmc_boot0_img_mcu1_0_release.xer5f
when I connect and load the ELF to MCU1_0 directly after a reset.

 Are you executing this test according to 4.3 CCS/JTAG this procedure?

4.3 CCS/JTAG
Apply attached patch as mentioned in faq-how-to-flash-ospi-using-ccs-on-tda4x-dra82-evm on PDK, which is
available as part of PSDKRA. This patch adds a utility that can be used to flash OSPI using CCS and JTAG
interface.
4.3.1 Flashing Instructions
1. Apply 0001-Add-support-for-flashing-OSPI-flash-using-CCS.patch on the PDK.
2. Change flag USE_CCS to yes in the pdk/packages/ti/board/utils/uniflash/target/build/uart_make.mk file.
3. Rebuild flash programmer by using make -sj PLATFORM=j721e_evm board_utils_uart_flash_programmer
from pdk/packages/ti/build.
4. Flash Writer binary would be available in pdk/packages/ti/board/utils/uniflash/target/bin/j721e_evm/
uart_j721e_evm_flash_programmer_release.xer5f.
5. Launch CCS and target configuration. For details on this step, see this.
6. From Scripting Console run loadJsFile("pdk/packages/ti/drv/Sciclient/tools/ccsLoadDmsc/j721e/launch.js")
from the CCS scripting console.
7. Once Java script is completed, load flash writer code in MCU_Cortex®_R5_0 core and Run it.
8. Application runs and displays 3 menu options on the CCS console, Erase OSPI flash, Flashing file in OSPI
and exit.
9. For erasing flash, select the start address and size to be erased.
10. For flashing a file, enter the file name with the full path, then enter offset where file is to be flashed, then load
the file using CCS scripting console (command to load is printed on CCS console). Once file is loaded from
scripting console, enter '0' on CCS console.
11. Press '2' on main menu to exit, after all files are flashed.

Regards,

Karthik

Hi Karthik,

I remember following these exact flashing instructions, but I wasn't aware that the patch also should be applied to the latest SDKs (PSDK version 10). Best way would be to test this with PSDK version 7.3, but currently the PSDK download from TI fails/is slow. I resolved two compiler errors for `ccs_main.c` and was able to build the target `board_utils_uart_flash_programmer`.

After that I opened CCS, launched the target configuration and successfully ran the launch.js script:

Running the cortex-r5 elf uart_j721e_evm_flash_programmer_release.xer5f did not succeed. Processor runs, but never gets to the main function. When halting the CPU, the PC is at address 0x4CA:

Loading the Cortex-R5 elf directly after reset (without running launch.js) was possible, but the program polls endlessly for the sciserver to respond (compare backtrace):

From my point of view this behaviour is expected, because the sciserver testapp is not running (it should be running on MCU_Cortex_R5_0 and I am using this core for the elf file).

Do you think this can be tested on a J721S2_HS device (with `make -j8 BOARD=j721s2_evm CORE=mcu1_0 board_utils_uart_flash_programmer_hs`)? I am not 100% sure, but SciClient is running on the SMS core for HS devices, right?

Edit: I tried running the board_utils_uart_flash_programmer_hs ELF on the J721S2 HS-FS variant and the MCU_CORTEX_R5_0 did not execute the ELF at all.

Regards,

Andreas

Hi Andreas,

Andreas K said:

Our usecase is to transfer bootloader code into the OCM RAM of the Cortex-R5 and run it

If transferring bootloaders is your use case, can you please try with SD boot mode. It would be simpler to start with that. 

Andreas K said:

Currently we had issues to finish the board initialization. This failed with the keywriter_img and flash_programming image (UNIFLASH Tool).

Could you confirm whether you're using an HS or GP device?

Regards,

Karthik

Hi Karthik,

If transferring bootloaders is your use case, can you please try with SD boot mode. It would be simpler to start with that. 

How do I correctly boot up the uart_j721e_evm_flash_programmer_release? I guess I have to put the uart_j721e_evm_flash_programmer_release.tiimage into the boot partition of the SD card instead of the .xer5f is that correct?

I am not interested in booting via the default tiboot3.bin, because we require a bare-metal emmc flashing application over JTAG

Could you confirm whether you're using an HS or GP device?

I am currently using a J721EXSKG01EVM (SK-TDA4VM) GP device and want to move on to a J721S2 HS Device when I have a working setup.

Best regards,

Andreas

Hi Andreas,

Andreas K said:

I am currently using a J721EXSKG01EVM (SK-TDA4VM) GP device and want to move on to a J721S2 HS Device when I have a working setup.

The SK-TDA4VM (Starter Kit) device does not have an eMMC. Please refer to the schematic. It seems like you are using the TDA4 Flashing Techniques document for the J721e_EVM device.

Regards,

Karthik

Hi Karthik,

I am aware of it, but the topic of this ticket is about Board and DDR initialization via bare-metal Cortex-R5 application. I just used the emmc0 sbl image, but the application aborted before even initializing the eMMC0.

A test on SK-TDA4VM (J721E_EVM) with ti-processor-sdk-rtos-j721e-evm-07_03_00_07 using sbl_uart_img


• Executed launch.js script with loadSciserverFlag = 0
• load the .xer5f from built sbl_uart_img
• Application runs and the UART1waits for tifs.bin

The next step could be to move the DDR Initialization before the SBL_SciClientInit(), but I am not sure if the SciClient is needed to initialize PLLs, Clocks and DDR. Do you know the required preconditions to perform the DDR initialization?

Best regards,

Andreas

Hi Andreas,

The rtos is not validated on the tda4vm-SK board. The validated SDK:

https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX-SK-TDA4VM/10.00.00.08

So if you have the sk EVM you can use the sd card as mentioned above by Karthik. We do not have a barmetal application that can be used to initialised DDR and even if that exists for EVM that's not validated on SK boards. 

And yes the device manager is needed for any of the clock requests.

Best regards,

Keerthy 

Hi Keerthy,

thanks for the answer, that's very helpful to know!

In that case do you know if the RTOS package can be used in combination with the XJ721S25AALZ (TDA4VE-HS)? The RTOS SDK Support will be required anyway in the near future for OTP Keywriting.

Best regards,

Andreas

Hi Keerthy,

one remark: With the insights from https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1418335/faq-j784s4xevm-how-to-load-tifs-using-jtag-on-hs-fs-device/5433552#5433552
I was able to test the SBL initialization, but it fails at the "Initializing DDR ..."-step and never prints "done". Do you know why this could happen?

Best regards,

Andreas

Hi Andreas,

Andreas K said:

step and never prints "done". Do you know why this could happen?

The relevant discussions is going on at this thread https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1420023/processor-sdk-j721s2-cannot-run-keywriter-via-jtag-xj721s25aalz-hs-fs-device  , Please follow the thread above for further support .

Reagrds,

Karthik