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/EVMK2H: building sbl

Part Number: EVMK2H

Tool/software: TI-RTOS

The TI wiki for the evmk2h indicates that it is possible to debug the SBL operation via code composer.

I would like to be able to do this to gain more familiarity with how this process works related to booting custom applications.

Can you point me to documentation on how to build the SBL app? I am currently using c:/ti/pdk_k2hk_4_0_2/packages/ti/boot/sbl ?

I have been able to successfully build the PDK, but it appears that rebuilding the PDK does not rebuild the sbl or any of the boot related modules.

Are there any step by step tutorials on using SBL to bring up a user app?

Thank you,

Richard

  • Hi Richard,

    Here is the wiki, explaining how to do the SBL build:
    processors.wiki.ti.com/.../L

    In your case for K2H, you should execute:
    cd ~/ti/processor_sdk_rtos_k2hk_4_02_00_09/
    source setupenv.sh
    cd ~/ti/pdk_k2hk_4_0_8/packages/ti/boot/sbl/
    make all BOOTMODE=spi BOARD=evmK2H SOC=K2H

    Best Regards,
    Yordan
  • I need a concrete example if possible. The wiki you refer to only provides generalities of the process.
    For example, when I build the sbl image and attempt to run it in the debugger, it loads ok and finds the main entry point, but it doesn't have any symbols loaded and it appears that it was built by the makefile with debugging off. How can I modify the build so that debugging support is included during the build process. Also I would like to see someone walk through the procedure of taking a user app and building it for use with the sbl and flashing it to memory so that it can actually be used. This is extremely poorly documented and what documentation exists is pretty much worthless.
  • Hi Richard,

    For example, when I build the sbl image and attempt to run it in the debugger, it loads ok and finds the main entry point, but it doesn't have any symbols loaded and it appears that it was built by the makefile with debugging off. How can I modify the build so that debugging support is included during the build process.


    When you build the sbl sources you get two binaries compiled in ~/ti/pdk_k2hk_4_0_8/packages/ti/boot/sbl/binary/evmK2H/spi/bin: MLO & sbl.out. The .out file is the one you should use to for debugging via JTAG.

    The MLO is used to flash the board with the program_evm.js script located in ~/ti/processor_sdk_rtos_k2hk_4_02_00_09/bin.

    As for the loadable application it is created via:

    ~/ti/pdk_k2hk_4_0_8/packages/ti/boot/sbl/tools/out2rprc/bin/out2rprc.exe --> for single core images
    or
    ~/ti/pdk_k2hk_4_0_8/packages/ti/boot/sbl/tools/multicoreImageGen/bin/MulticoreImageGen.exe --> for multicore images.

    For example, lets say you've built & debugged the qmSRIORtrK2HArmBiosTestProject via CCS. You now have the binary ~/ti/pdk_k2hk_4_0_8/packages/MyExampleProjects/qmSrioRtrK2HArmBiosTestProject/Debug/qmSrioRtrK2HArmBiosTestProject.out

    you can convert it using out2rprc.exe and call the newly created binary app:
    out2rprc.exe qmSrioRtrK2HArmBiosTestProject.out app
    Copy the newly created app in ~/ti/processor_sdk_rtos_k2hk_4_02_00_09/prebuilt-images. Now you can program it on the board flash along with the MLO using the program_evm.js and the application will be loaded and executed by the MLO (I've verified this (replacing the default app image) on K2G board using sd card).

    Best Regards,
    Yordan
  • When I build the SBL it DOES NOT have symbols defined correctly. the SBL image jumps to code that is grayed out when I load it into the evm board via CCS and hangs when I try to run it.
  • Let me check further..

    Best Regards,
    Yordan
  • Here's what I have done so far:

    I updated code composer to version 8.0.0.00016 (the latest from the ti website)

    I installed processor sdk for the evmk2h version: 4_02_00_09 (also the latest version)

    I rebuilt the pdk and all of the example projects and they appear to work correctly when run in code composer.

    (BTW there is a bug in the makefile for the example projects. It points to the wrong version of the compiler and I had to fix it)

    I then rebuilt the sbl using the makefile I found in folder: c:\ti\pdk_k2hk_4_0_8\packages\ti\boot\sbl using the command:

    > gmake all BOOTMODE=spi BOARD=evmK2H SOC=K2H

    I receive log messages that indicate the following files were successfully compiled from their respective directories:

    sbl_main.c
    sbl_rprc.c
    sbl_spi.c
    sbl_slave_boot.c
    sbl_a15.c
    sbl_soc.c
    SPI_soc.c
    sbl_init.S

    The linker then runs successfully creating sbl.out

    the objcopy utility runs successfully creating sbl.bin

    then for some reason I cannot determine the makefile indicates failure when it attempts to run tiimage even though it appears that the path to the tiimage program is correct.

    I was able to navigate to the folder that holds the sbl.bin file and successfully create the associated MLO file that tiimage was attempting to make from the make file by keying in the command manually.

    The size of the resulting MLO file matches the original MLO file that was in the folder prior to rebuliding sbl.

    I then started code composer and connected to Arm0 using the following gel file:

             c:\ti\ccsv8\ccs_base\emulation\boards\xticevmk2x\xtcievmk2h_arm.gel

    I then loaded the sbl.out file that I just built and it successfully pauses at main() .

    At that point if I attempt to step into the SBL_socInit() call immediately after the opening of main, The program cursor ends up on a line that is "greyed out"  inside of a section that is wrapped with:

    #if defined(A15 _CORE)
       void (*monitorFunction) (void (*)(void), ...);
       
       /* A15 startup calls */
       monitorFunction = (void (*)) 0x1000;
       (*monitorFunction)(SBL_setNSMode);   <------- The program cursor stops here and this whole code segment is greyed out, I guess because it thinks that A15_CORE is undefined.
       (*monitorFunction)(SBL_a15EnableNeon);
       (*monitorFunction)(SBL_a15EnableSMP);
    #endif

    Anyway, I am unable to successfully step through the code any further at this point and the program appears to hang with no other indications or warnings if I allow it to run by hitting F8.

    If I interrupt the running program, the program is stuck in an infinite branch loop at address 0x900 where there is an instruction:

    00000900:    b  0x900

    So clearly what appears to be a successful build does not work in the debugger and I need to be able to understand if I'm doing something wrong.

    Also, I was able to flash the NOR memory using MLO and another app to see if I could get the sbl to run my simple test program and it shows nothing on the serial output port when booting in NOR ARM

    mode. (i.e. evmk2h boot config switches set in state 0010 after flashing NOR spi eprom).

    This whole procedure is error ridden with mis-configurations from TI and completely inadequate documentation.

  • Hello Rahul
    I am having the exact same problem as Al described. However when I investigated adding this fix into my copy of sbl_soc.c I noticed that my code differs from that which you
    quoted in the previous post.


    I recently installed Processor sdk version 04.02.00.09 on windows as well as the latest version of code composer.

    The #ifndef on line 10 in your post is the following in my code:
    #if defined(A15_CORE)

    also immediately after line 17, prior to the #endif, the following call is inserted:
    (*monitorFunction)(SBL_a15EnableSMP);

    Can you comment as to whether these changes are correct? ( It appears your version of code is different than mine ).

    I am going to attempt to insert your fix and retest to see if I am able to get further along.
    One thing also is that the section wrapped by the #if defined(A15_CORE) statement is greyed out in code composer when I attempted to debug it even though my reasearch showed that
    A15_CORE was in fact defined when the source code was compiled by the make file. I am going to change back the code to your test for #ifndef SECURE_BOOT to see if this makes any significant difference as well.
  • Hello again,
    After inserting the code on line 20 in your prior post, and changing the #if defined(A15_CORE) to #ifndef SECURE_BOOT on line 10, I was able to run the SBL and succesfully transfer to the application I had previously flashed into NOR memory. So that appears to have fixed the hangup I was having. My only question now is which ifdef on line 10 is correct. As a side note, the sbl successfully loaded the user app from NOR flash even with the #if defined(A15_CORE) statement in place, so for now I will leave it as is, but I'm curious as to why code composer is indicating that the A15_CORE symbol is undefined eventhough the makefile does actually define it when sbl_soc.c is compiled.

    I'm going to attempt to reflash MLO along with my application to see if I'm successful.

    If I run into any more issues, I will repost here.

    Richard
  • Richard,

    Sorry to know that you are running into these issues with the SBL code and agree that we have some gaps and can always do more in making the user experience friendlier with our software documentation.

    I will try to attempt to help you with this setup but it may taking a few back and forth responses to get everything right with the setup.  First let me start with the scenario that differentiates a GEL file and the bootloaders before attempting to help you with your setup.

    GEL and bootloader are two conflicting mechanism of loading your application. GEL should only be used when connecting to device in no boot mode when the ROM code on the device does nothing but idle the ARM core to wait for user to connect using the emulator. The SBL is meant be a mechanism that performs similar functions  to a GEL but in production booting scenario where image comes over flash and ROM code sets up the boot peripheral and clocks.

    When debugging the SBL, it is recommended that you take the GEL files out to confirm that the GEL is setting the clocks and the DDR correctly apart from confirming the loading of the application.  When debugging the SBL, ideally you should connect to the core in no boot/SPI boot mode without GEL file and then load the .out.

    Moving on,  the SBL is production loading software so is typically always compiled with optimized settings to reduce the size and the boot times hence to debug the SBL, you need to change the compiler flags so that you can perform full symbollic debug.  The current compiler settings are in the makefile located at pdk_am57xx_1_0_10\packages\ti\boot\sbl\board\evmK2H\build

    # FLAGS for the SourceFiles
    
    CFLAGS += -Wall -O3
    
    SRC_CFLAGS = -I. $(CFLAGS) -g -gdwarf-3 -gstrict-dwarf -Wall

    You need to change these by removing -O3 to generate the symbols for single stepping. Please note the board library, UART, SPI drivers may also be built with release settings so you might not be able to step into driver APIs. The boot monitor calls are calls into the BootROM code that need to be performed when A15 is in secure supervisor mode so while you can see the assembly, you can step into boot monitor functions without hardware break points.

    Finally, I noticed that you are using Processor SDK 4.02 release in which the ARM GCC compiler was upgraded from 4.9.3 to 6.3.1 just before the release which seems to have introduced a bug. The init code from t he previous version of the compiler was setting the VFP module in the ARM core but in the later release, this module is no longer enabled hence the SBL code needed to be modified to add SBL_VFPEnable as described in the E2E post here:

    https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/659405/2435779#2435779 

    this is being tracked  using bug ID PRSDK-3549 and will be resolved in the upcoming release that will be available in 1st week of April.

    Please try some of the things that we have discussed  here and let us know if some of your issues are resolved. I can provide further assistance if you are still having issues with this setup.

    Regards,

    Rahul

  • Richard,

    Another note after reading your post. We are not supporting CCSv8 with the Processor SDK RTOS software yet. I would stick to the CCS version in the Release notes. CCS is just an IDE environment for code development so minor version updates don`t matter from SDK perspective but if you have updated to CCSv8 then you may run into issues with the pdkProjectCreate script which expects the verison of CCS to be ccsv7.

    Current SDK plan is to update to CCSV8 in 2H2018.

    Regards,
    Rahul
  • Richard,

    I saw your posts on the other thread but some how that post seems to be deleted so let me directly respond to your post there.

    You can pull the updated SBL code from the external GIT. This version has been system tested to confirm the fix:
    git.ti.com/.../sbl_soc.c

    Regards,
    Rahul
  • Hi Rahul,
    Thanks for your help on this. I actually found another thread where you were helping another user with the same problem I was having.

    Couple of comments.
    I resolved the problem with pdkProjectCreate script by updating the reference to ccsv7 to ccsv8 in the makefile and that allowed all of the example projects to build correctly.

    I'll keep the other notes regarding the debugging of the sbl for future reference as we have some special needs on my program that will require it to be slightly modified, which is why I wanted to be able to debug it.

    The information I found in the other thread which I link to below allowed me to finally solve the problems in getting the sbl to boot and transfer control to my test app.

    Here is the link to the thread that got me going. I was able to rebuild MLO, and convert my test app to binary and flash them into the NOR memory and after setting the board to NOR boot mode, everything worked!

    I did have a question which I posted in thread referenced here:

    e2e.ti.com/.../2488108

    Thanks to both you and Yordan for your assistance on this.

    Richard
  • Ah, I just saw your note about the deletion. Anyway, things seem to be working now. So Thanks again. I'll review the sbl_soc.c file from the git hub to make sure I'm in sync.