• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 104 subscribers
  • Views 2068 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Linux/66AK2G02: Using u-boot to load DSP and ARM for IPC

Chuck Peplinski
Genius 5770 points
Part Number: 66AK2G02

Tool/software: Linux

My program on K2G uses both DSP and ARM with the IPC module for communications.  The DSP has to start first, then the ARM.  Both processors run TI RTOS, but this is a question about U-Boot.  I want to use u-boot to load the images for various reasons.  Loading the ARM image is straight forward.  

I'm using the 2017.1 version of ti-u-boot.  I see that there is an "rproc load" command, but it wants to have a binary image of the DSP code.  I see that there is a tool, C:\ti\ccsv6\utils\tiobj2bin\tiobj2bin.bat that might be able to make a bin file.  Is that the recommended tool?

I see there is also a "bootelf" command.  Since it starts the ARM, it's not appropriate for the DSP.  But it seems that this would be best.  Wouldn't it be best to have an "rproc loadelf" command?

Is anyone else loading up such a two part program from uboot?  Any recommendations before I dive in?

  • 0
    TI__Guru**** 161600 points
    Hi,

    I've notified the RTOS team. Their feedback will be posted here.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Guru 50170 points
    Hi, Chuck,

    I need to find out what does that rproc do. If it is a full blown of the remoteproc in kenrel, then it is possible. However, I suspect that will be the case. In addition to downloading the image, remoteproc run during kernel bootup also examines the resource table to modify the MMU if necessary.

    I am not familiar with RTOS, but would it possible to have RTOS boot code to load the DSP then ARM? or in the beginning of the ARM code, it download the DSP?

    Rex
  • 0 in reply to Rex Chang
    Genius 5770 points
    when you say kernel, do you mean the uboot kernel? The Linux kernel is not involved here. This is u-boot. I've been figuring this out and I believe that I will have to use uboot to load and start what TI calls the "SBL" (secondary boot loader) that can start both the ARM and the DSP. I want to use u-boot so that I can fetch a new image over ethernet. But the program I'm loading is not Linux.

    Here is my current summary:

    1) The uboot loadelf command can place an ARM image in memory identically to the debugger. I know this because:
    a) 'setenv autostart no' causes uboot to loadelf but not start it.
    b) Connect with the debugger (no gel file).
    c) use load/verify. It passes.
    I check this using the GPIO_LedBlink_evmK2G_armExampleProject program.

    2) If I now try to execute I will land in a uboot exception handler. This is true whether I let uboot start the program or I set the PC there and step with the debugger. Is this due to a memory conflict? Is my program trashing uboot? Am I violating the MMU access restrictions of uboot? I want uboot to get out of the way.

    3) If on the other hand I use mkimage and then bootm, I get no exception but the program does not run. mkimage adds a uboot header, but something still is not right.

    4) The elf files created by the C6000 linker are not suitable to load with "bootelf". There are no shdr's. I see that I must use hex6x to create bin files which I should be able to load. C:\ti\pdk_k2g_1_0_5\packages\ti\boot\sbl is the example of this. This shows a multiprocessor boot image being created and the SBL being used to start it.
    - Can this SBL image be loaded directly from uboot? Will it run?
    - Will a DSP image created with hex6x run using rproc from uboot?
    - Once the DSP is started, can it start the ARM? I need to look at the SBL code.
  • 0 in reply to Chuck Peplinski
    TI__Guru 50170 points
    Hi, Chuck,

    Sorry, it took me a while to get back to you. Your questions are a bit hard for me to answer because you touched some RTOS area, but I'll try.
    The kernel I meant is the Llinux kernel. TI provides 2 environments on the SoC, RTOS and Linux. U-boot is in the Linux camp, but trying to run RTOS LedBlink example, it won't work. The set up are different. You can try creating an SD card using RTOS package. The MLO in RTOS will set up correctly to run the RTOS GPIO_LedBlink ARM example. I don't think mkimage of a RTOS example will work in Linux environment.

    In Linux environment, any DSP .xe66 images loadable/runnable through CCS can be download through Linux Kernel remoteproc driver during boot up. However, in u-boot, the rproc only support download image to pmmc (power management controller), not DSP. "rproc list" shows available remote processors.

    The RTOS MLO does not have ethernet enabled. It does only basic initialization, power, and pinmux setup. Instead of getting image through ethernet, if the image can be on the SD card, then RTOS MLO may be a better fit.

    Rex
  • 0 in reply to Rex Chang
    Genius 5770 points

    Thanks.  

    My goal is to use uboot in development.  uboot has the ethernet support to load in a new image for testing.  We would not use uboot in a project.  There we'll go straight to the MLO from QSPI flash.  The product doesn't require Ethernet support.

    I've used Linux and U-Boot in lots of previous projects.  We're "forced" back to TI-RTOS for this project and I'm trying to get a good development environment.  I've uncovered a collection of roadblocks.

    The first blocker:  We have conflicts in the use of internal memory.  My initial tries crashed because UBoot is running from internal memory and this was being overwritten by loading a new program.  So that would need to be solved first.  If that were the only problem...

    Next we have the question of what constitutes a complete and appropriate image format.  A raw elf file does not contain the necessary system init code.  A kernel uImage does.  An MLO file contains headers that the SBL loader uses.  Again, this should be able to be solved.  

    Finally we have the question of the DSP code.  You say that the UBoot rproc doesn't handle the DSP.  I thought it did show in the list.  But if it doesn't (the name on screen isn't very clear), that's another hurdle.  As is the fact that elf files generated by the TI DSP C compiler apparently contain no "shdr" information, and this is required by uboot to load elf.

    Each of these things should be solvable by some programming time devoted.  The roadblocks listed here mean we're stuck with JTAG download for the immediate future.

    Thanks, I'll mark this answered.

  • 0 in reply to Chuck Peplinski
    Genius 5770 points
    Correcting a typo in the third sentence of my response:
    We would not use uboot in the released product. There we'll go straight to the MLO from QSPI flash. The product doesn't require Ethernet support.