66AK2G12: Bootloader Questions

Bernhard,

Bernhard Seiz said:

Is the RBL also able to have the DSP core to be the boot master? With BOOTMODE pin 5 == 1?

Overall as per the device data manual, the device is primarily designed to be an ARM master boot device. There is limited feature set validated for DSP boot master but all of the device collateral and software leverages ARM as the boot master as this covers 95%+ of our usecases. Curious to know why you need the DSP to boot first in your usecase so any details you can provide are appreciated.

Bernhard Seiz said:

What is the DSP core counterpart for the ARMSS Boot RAM Memory Map (TRM 4.4)?

The DSP equivalent of ARM Boot ROM is a L2 ROM on the device when you connect to DSP on the device using an emulator you should be able to see the DSP waiting in the L2 ROM space at 0x20b0_0000. you can locate this in the Memory map provided in the TRM.

Bernhard Seiz said:

In case of XIP boot the GPMC interface is used, isn't it?

Yes, GPMC interface is used with parallel NOR in case of XIP boot.

Bernhard Seiz said:

If so, how is it possible to give the RBL information about the required GPMC timing to access the connected memory chip? There are entries in the XIP boot parameter table (TRM 4.3.3.6 XIP Boot Parameter Table). But by default thy are not used (Options: Default Value 0). Is a multistage boot necessary for this?

The BOOTMODE pins are used primarily to guide the BootROM to configure the peripheral. There is a default boot parameter table loaded in by the ROM with timing settings that are supposed to be conservative and know to work with most parallel NOR flashes. However, we have a Boot errata (Advisory46) for this boot mode with regards to GPMC timings that you can refer here:

http://www.ti.com/lit/er/sprz451b/sprz451b.pdf

Bernhard Seiz said:

In a multistage boot I have to use more than one boot medium?

No, multistage boot doesn`t require to use more than one boot medium. Mutli-stage boot is recommended on heterogeneous multi-core devices as it allows for customization of external memory configuration, customizing/speeding up boot flow and to allow the initialization to also boot up slave cores. We provide a secondary bootloader as part of Processor SDK RTOS offering which you can refer to here. In this multistage boot, the secondary boot loader will continue from where boot ROM has left of and will set pinmux, configure DDR and load and start execution of application on both ARM and DSP. ROM loads the SBL from base of flash and the application from an offset from the same boot media.

Hope the responses help. Let us know if you have any further questions.

Regards,

Rahul

Bernhard,

Thanks for clarifying your background and experience with C6657. If your application only requires to only use DSP for the most part, you can have the ARM load and run the application using the DSP using SBL and then either go to lower power state/sleep.  

The SBL boot mechanism doesn`t use ROM re-entry described in TRM, it has the infrastructure to load and run applications without having to re-enter boot. ROM re-entry is available on these devices but not required unless there is any compelling reason to re-use a function written in the ROM.

You should be able to leverage a lot of your development on C6657 on K2G device as K2G devices uses similar CSL and driver API interface for all the peripherals common to the same SOC. Processor SDK RTOS software offering that we provide for K2G is an evolution of the MCSDK baseline that we had on C6657 device. Current version of the software for C6657 is also based on the Processor SDK baseline

Regards,

Rahul