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.

RTOS/66AK2G12: DDRLess system Using QSPI flash for application boot

Part Number: 66AK2G12

Tool/software: TI-RTOS

How to develop a DDR-less system and use external QSPI memory for K2G? The QSPI flash is to be used for both boot up and external memory.
Do you have any link or document like sprac45a, "Sitara AM437x DDR-Less System How-To Instructions and Benchmarks," for K2G?
I would like to know any changes need to be done based on RTOS PDK.

CCS  Version: 7.2.0.00013
pdk_k2g_1_0_7
processor_sdk_rtos_k2g_4_01_00_06

  • The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • Looping the RTOS team to elaborate. They will post their feedback directly here.

    Best Regards,
    Yordan
  • Joshua,

    Currently most of the our DDRless system documentation is aroung AM335x and AM437x devices and we have not extended this to the Keystone II platforms since most of the usecase for these class of devices involves use of DDR memory. 

    the concepts discussed in the application notes are something that can be applied to all the devices. Steps to create a Platform definition with no DDR so that linker places code only in MSMC and on chip memory still applies. In terms of booting from QSPI, the ROM bootloader on this devices doesn`t support Execute in place mode with QSPI boot so you will need to move code to onchip memory however post boot the QSPI IP can be used to execute code in XIP mode. when using QSPI based external memory, the configuration of direct address mapping also works the same way on K2G platforms as on AM437x platforms as discussed in the application notes.

    Regards,

    Rahul

    PS: Just a note, please ensure that your ARM and DSP application binary can run from onchip memory before implementing a DDR less system. Our implementations on AM437x and AM335x have required us to strip down memory requirements of the application by allocating smaller stacks/heaps in different components and also by cutting out non-essential drivers to fit in the onchip memory.