• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 1263 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.

Multicore Image Booting

Product Design Medha
Intellectual 430 points

Hi

I am using EVM6678. My application uses the same image on all 8 cores(i.e. with the emulator in place I load the same .out file on all the cores). I want to migrate to loading this image in NOR flash and booting all cores from it.

We successfully loaded a single core image on NOR which toggles the LEDs. In the process we found that if we place the code, stack and data in L2SRAM booting was not successful. If we change the platform such that code, stack and data are in either MSMC or DDR3 the code was booting

Q1. What is the reason for this behavior. Specifically, what made the image boot successfully when placement was changed to MSMC or DDR3?

While attempting a simillar change in platform or attempting to split the L2SRAM or MSMC or DDR in the multicore application, the program was returning errors at run time or compile time respectively.

Q2. What is the step by step procedure to load the same image on all the 8 cores via booting from NOR?

Srikanth

  • 0
    Intellectual 535 points

    Hi

    If you are NOT using IBL.
    A1-1. RomBootLoader uses some  L2RAM for working area. 
               So your applications must not use reserved area by RBL. (I don't know stack can or can not )
    A1-2. RBL runs on Core0 , so CoreN(N:1~7)  L2SRAM Address must 0x1C800000 (C:corenum)  in the boot table.

    bye

  • 0 in reply to Kazunori
    Intellectual 430 points

    Kazunor,

    Thank you for the response. I am using the IBL in the I2C EEPROM,

    1. Does the Rom Boot Loader still use the L2SRAM area? If yes, what specific memory location would that be?

    2. How do I specify different L2SRAM address for each core in the boot table when I am using the IBL? I did not do this when running the code with emulator.

    3. The question still remains: what is the step by step procedure to load the same .out file on multiple cores to boot from the NOR flash?

    Srikanth

  • 0 in reply to Product Design Medha
    TI__Intellectual 2220 points

    Hi Srikanth,

    Q1. What is the reason for this behavior. Specifically, what made the image boot successfully when placement was changed to MSMC or DDR3?

    [Ivan] - By default, NOR boot does go through IBL and uses the first 0x20000 bytes. If you have an updated FPGA which does not use IBL and only boots from RBL, this should not be a problem. The HUA demo included in our BIOS-MCSDK package has a custom RTSC platform which accounts for this L2SRAM offset.

    Q2. What is the step by step procedure to load the same image on all the 8 cores via booting from NOR?

    [Ivan] - Please take a look at the MAD Loader, http://processors.wiki.ti.com/index.php/MAD_Utils_User_Guide. This tool will create a single binary that can be flashed into NOR, and upon booting, will load each core with specified code. Please also take a look at our Image Processing demo, which is a multicore application that has an example of this tool in use.

    2. How do I specify different L2SRAM address for each core in the boot table when I am using the IBL? I did not do this when running the code with emulator.

    [Ivan] - I want to point out that each core can use 0x00800000 as its personal local address. The global address comes into play when other cores or peripherals want to look into the CorePac. When running the code with the emulator, it knows that the address is local to the core that it is running on.

    Let me know if this helps.

    -Ivan

  • 0 in reply to Ivan Pang
    Intellectual 430 points

    Hi Ivan,

    Thank you for the response. We figured out the issues w.r.t Q1 and modified the placement of code and data in our application.

    But we have doubts w.r.t the usage of MAD tools. We started with understanding the MAD user guide.

    1. We understand there are two use cases for MAD utilities: Prelinker Bypass and Prelinker modes.
    2. Honestly we are not very sure on which mode to choose for our application. As indicated earlier, our application uses the same code in all the cores. However when we tried the placement of code, data memory and stack in DDR3 in the same location in all cores the application was not working(with the emulator). So we decided to allocate separate locations to place the data and stack for each core on DDR3 and to place the code in L2SRAM(with the reserved memory set aside). This placement of Code, Data and stack  is the only difference between each core's code. This configuration was working.
    3. Considering all this and that our application has substantial DDR to allow for duplication of code and data, Which mode should we choose?
    4. How can we generate the EXE files required as inputs for MAD for image creation. We could NOT generate any EXE file as output from CCS build. Please let me what I missed here. All that we have are the .OUT file which need to be transferred to each core.
    5. After this stage, I think we are going to get the ROMFS file to take the process to the next level.

    We request your guidance on Points 2, 3  and 4 to get started with application deployment. Please do correct me, if my interpretation is incorrect in any of the above steps.

    Srikanth

  • 0 in reply to Product Design Medha
    Intellectual 820 points

    Hi,

    I would prefer not running any of peripheral libraries other than core 0.
    Because as far as I know, there are some restrictions at the peripheral libraries about initialization procedures that prevents them to initialize on cores other than core 0. You can search libraries for DNUM variable, and see if there is core dependency exists or not. I remember platform library is core dependent. If you are using it, you may want to look at this point.
    Instead, I would prefer writing a predefined structure on different sections of memory according to the running core number, and after booting checking them using CCS memory window.

    Q4: you can directly use your .out files. No problem.

    koray.

     

  • 0 in reply to Product Design Medha
    TI__Intellectual 2220 points

    Srikanth,

    2. Please try Prelinker Bypass mode first - it is simpler and should not have any limitations in what you are trying to do. Make sure you have a working configuration with the emulator. The MAD loader works similar in the way you load from the emulator. It loads each core with respect to the binary you tell it to load (minus debug symbols). If it did not work with the emulator, then it most likely will not work with MAD.

    3. It should not matter if you have duplicated code/data/stack in DDR, as long as your application is able to work with it.

    4. As koray mentioned, .out files will work. MAD looks for executable files generated by our C6000 compiler.

    Your steps should be:

    1. Make sure your application(s) run without errors in CCS with emulator
    2. Create a MAD image in Prelinker Bypass mode
    3. Try debugging the image from step 2 in CCS with emulator (section 3.4 of the MAD user guide). If the outputs are not as expected, pause the cores and check their PC. If it did branch into your application code properly, load your program's symbols and try to see where the error occurred.
    Let me know your progress. I can help you debug as we go along.
    -Ivan
  • 0 in reply to Ivan Pang
    Intellectual 430 points

    Pang & Koray

    Thank you for your responses. It did solve our problem and we are now able to boot from multicores. However, my job would have been much easier had the MAD user been a little more detailed. Particularly on how to use the python program.

    Srikanth