CCS/EVMK2G: boot process

Nagaraju Sripathi said:

1. Is there a possibility to skip SBL and the control transfers to application? If so how to do that?

SBL is required for the following three reasons:

1. Setup pinmux and clocks for application  (You can do this in application code but this is one unified place where this can be done before multicore application boot)

2. K2G is ARM boot device which means the ROM will only boot up the A15 application. A15 needs to boot up DSP core.

3. K2G ROM doesn`t setup the DDR (external memory). ROM can load only code in device onchip memory.

4. This is user level bootloader so it is easier to debug and add new features. ROM bootloader is fixed function bootloader in device and source code is not provided for debugging boot.

Nagaraju Sripathi said:

2. what is the reset vector address ?

The reset handler in PDK is named as 'Entry'. The reset handler sets up the stack pointers for all the modes. The FIQ and  IRQ shall be disabled during this. Then clear the BSS sections and finally switch to the function calling the main() function. The Entry from Sbl_init.S is placed at the start address of SBL_MEM (0x0c0b0000) in the linker.cmd file for SBL.

Nagaraju Sripathi said:

3. I believe "Entry"(in sblinit.S) is the location pointed to by reset vector and on every powerup control jumps to Entry label and then performs below steps

- After POR bootrom executes and read DEVSTAT to know the bootmode
- DEVSTAT register is copied to MSMCRAM (as per page 279 of spruhy8I.pdf) address space and boot re-entry is pointed to this address location
- Transfers the control to main defined in sbl_main.c
- sbl_main.c then copies the image based on Bootstrap pins and jumps to the application

The TRM only provides details of ROM bootloader implementation. The boot flow with SBL is described here:

Nagaraju Sripathi said:

4. Is it possible to integrate the source code of "uart_evmK2G_flash_programmer.out" in our project workspace and rebuild the application? If yes, where the source code located?

Yes, you can integrate this code in your application if required. The source for this utility is located in the PDK in the following folder:

pdk_k2g_1_0_1x\packages\ti\board\utils\uniflash\target

Nagaraju Sripathi said:

5. The batch file "program_qspi_flash_app.bat" flashes the application at memory location 0x80000. Is it possible to change this location? If so, how to do that?

Yes, you can change the location for where the application is programmed on the flash. This needs two changes :

1. Change the offset in SBL :  Update the following MAcro in the file sbl_qspi.c:

#define QSPI_OFFSET_SI              (0x80000)

2. Change the offset provide in the flash writer. (NoteL program_Qspi_flash_app.bat doesn`t seem to be part of PDK. Is this your file). Instructions for QSPI flash programmer is provided here:

https://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/rtos/index_Foundational_Components.html#qspi-boot-mode

dslite.bat --mode processors -c <COM Port> -f <Path to the binary to be flashed> -d <Flash Device Type> -o <offset>

Nagaraju Sripathi said:

1. How to change the compiler to "C:/ti/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-gcc" in CCS?

Right click on the project and go to the Show Build Settings-> General . You should see the compiler version there. 

Click more and add your compiler install directory to the Toolchain discovery.path  and add the version in the project when it is found.

Nagaraju Sripathi said:

2. I see the makefile using nonos related libraries. Does the uart_evmK2G_flash_programmer build with TIRTOS? 

The UART program that this is part of Board Utils is bare-metal code that is not TI RTOS dependent as it is just a tool for flashing and has no RTOS requirement given it is single task.

Nagaraju Sripathi said:

3. Our application is using TI RTOS. we want the uart_evmK2G_flash_programmer source code added to our application source code and build a TIRTOS image. what settings to be set in CCS project to achieve this?

You can include this in your TI RTOS Application if required.  In this case you can build with the rtos version of the OSAL. OS Abstraction layer is the only thing that needs to change when incorporating bare metal code into RTOS code. OS Layer handles interrupt configuration. timer management etc and has RTOS and no-RTOS implementations of the same APIs.

Nagaraju Sripathi said:

4. Can the uart_evmK2G_flash_programmer code run on DSP?

Yes, the UART flash programmer code could run on the DSP as the drivers used in that application exist on both the cores. We however have done all of our testing from the ARM core only.

Regards,

Rahul