• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 1192 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/EVMK2G: What Bootloader for TI-RTOS?

Chuck Peplinski
Genius 5770 points
Part Number: EVMK2G
Other Parts Discussed in Thread: UNIFLASH, 66AK2G02

Tool/software: TI-RTOS

Our application will use both ARM and DSP running TI-RTOS.  Our application will include code that must be treated as secure IP.  I suspect that secure boot is an issue.

I see that the SBL is supported (http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_AM57x?keyMatch=sbl&tisearch=Search-EN

We have much experience with U-Boot and we find this quite attractive as U-Boot supports USB and Ethernet for firmware update. It looks to me as if the SBL would be used to load U-Boot and U-Boot would load the actual applications for the ARM and the DSP and start them.

Is this a common approach?  Can you offer any guidance on secure boot?

  • 0
    TI__Guru** 116180 points

    Chuck,

    Yes, for the RTOS SDK. Currently SBL is a recommended to boot and flashing package in the SDK that we recommend to deploy ARM and DSP applications. there are tools provided in the SDK to combine the ARM and DSP image which will then be deployed on both the cores by the SBL that will run on the ARM that is the boot master. Currently, we support only non-secure general purpose devices with SBL.

     

    We have secure boot development underway and will have an Processor SDK RTOS SECDEV release available in the 2Q17 time frame. For early access to this release, you will need to work with your local TI contact/business teams as the secure boot software to protect IP will be distributed after signing NDA agreements through our secure portal www.ti.com/mysecuresoftware. This also would require you to work with HS variant of the silicon/EVM.

    We will continue to support U-boot and boot monitor for the A15 cores both for general purpose and HS silicon using Processor SDK Linux and Processor SDK Linux SECDEV if you want to have the option to use U-boot.

    In terms of your other question regarding flashing and firmware updates, we are considering supporting a tool like Uniflash that is supported for sitara devices for this product. I can`t provide a timeline for this feature support as the discussions are in early stages.
    processors.wiki.ti.com/.../Sitara_Uniflash_Quick_Start_Guide

    Regards,
    Rahul

  • 0 in reply to Rahul Prabhu
    Genius 5770 points
    Uniflash looks interesting, but wouldn't it make more sense to rely on the secure version of UBoot? We'll be investigating both.
    I'm most interested to use a boot loader to drastically improve the turn around time when changing code. Today on K2G I need to go through a 3 minute process of disconnect, connect, load, start on each processor just to make a one line change in code. I don't always need the debugger, so I'm thinking to have the build make a binary in a tftp server and have uboot load it and start it.
  • 0 in reply to Chuck Peplinski
    TI__Guru** 116180 points
    For RTOS, the only way available to run updated software without debugger is to use SD//MMC but that also requires user to insert on the PC slot update and put it back into the EVM. Other Option is to put DSP binary into network file system and have the remoteproc and IPC to load the DSP but this adds additional complexity as u-boot and Linux may need to be modified to carve out memory and resources that are dedicated for the DSP.

    Appreciate your feedback, I will communicate this with the development team and see if we can enable this functionality. I doubt that Linux SDK can enable this from u-boot as the SDK needs to have the code up streamed to mainline and there are some restrictions in enabling and loading secondary cores in uboot but we may be able to have the Linux boot a DSP binary from Network filesystem.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Genius 5770 points
    We should be able to use UBoot without Linux. It just loads bits into memory. Then we need the appropriate code to start the images, but this must already exist.
  • 0 in reply to Chuck Peplinski
    TI__Guru** 116180 points
    Yes, you can use u-boot. All I meant was that the customization to load the DSP memory and start it will be left to the end user as the Linux SDK software will only support what has been upstreamed to mainline.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Prodigy 25 points

    Rahul,

        I attempted to run a .out file (ARM) generated in CCS and tested to blink an LED on the 66AK2G02 EVM. I am using the SD card image from the Processor SDK. The program I wrote was based on the "Hello Example" in the resource explorer.

       Running the program over the debug link from CCS works as expected, using the K2GEVM.ccxml debug config. However, when I attempt to load from U-Boot by using "fatload mmc 0 ${loadaddr} hello_K2GEVM_CortexA.out" and running it with "bootelf", I see that the program is loaded and U-Boot reports the correct entry point:

    => fatload mmc 0 ${loadaddr} hello_k2gevm_cortexa.out
reading hello_k2gevm_cortexa.out
1029956 bytes read in 57 ms (17.2 MiB/s)
=> bootelf
## Starting application at 0x80005100 ...

    The program, however does not blink the LEDs as it did when loaded via the debug tool in CCS.

    I tried connecting with the debugger and inspecting the RAM, and could see it was loaded, and attempted to jump to the entry point by placing it in the PC register. However, this did not result in a load as expected.

    What did result in a successful startup, however, was loading the program in U-Boot and running the bootelf command, then connecting the debugger, suspending, using Run->Reset->CPU Reset (SW), placing the entry point in the PC register, and resuming execution on the ARM core.

    Are there any suggestions as to how I might put the CPU into a state (From U-Boot) to allow the standalone executable to run?

    Best Regards,

    Jon