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.

Using SPI boot mode in C6678 EVM

Other Parts Discussed in Thread: TMS320C6678

Hi All ,

I understand from the datasheet that TMS320C6678 processor supports booting from flash devices (using SPI.EMIF16 boot modes). I want to have a single flash device on my system that will hold the application image and i wish to boot directly from this flash device on power on.

If i configure the boot mode pins to select the required boot mode (SPI or EMIF16) and place my application image in the flash device will i be able to achieve the functionality of bootling from Flash device. Does the ROM bootloader have the support to copy the application image from the flash device (depending on the bootmode pins configure) to DDR and execute the same i.e. non XIP (Execute In Place) mode?

I understand from an earlier post that TMS320C6678 Silicaon version 1.0 chipsets have a PLL lock issue and a workaround required to be implemented.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/101820/358059.aspx#358059

In the EVMs shipped by TI the workaround is implemented in a code sitting on the I2C based EEPROM.

In my case (where i have a single flash device and no EEPROM on board) can i have this workaround implemented in the applciation code sitting in my flash device? To Sum up what i essentially expect to happen on power on is:

(assuming that I have interfaced an SPI based  NOR Flash to TMS320C6678 processor)

1) I configure the bootlmode pins of processor to SPI boot.

2) On Power ON ROM bootloader copies the image in the SPI based NOR flash to DDR and executes this. The PLL is in bypass mode .

3) When the application code executes it first implements the PLL Lock up workaround suggested by TI in the errata. It than initializes the PLLS and proceeds.

Can i achieve the above steps? Please let me know if there are any mistakes in my understanding.

Also is there a way to test this on the TMS3206678 EVM ?

-Anil

 

 

 

  • Hi Anil,

    You can do that with both this mode by using the PLL fix that we provided in the link below.

    http://processors.wiki.ti.com/index.php/C66x

    Even though this is for only PCIe, Ethernet or SRIO, you can expand to your desired boot mode.

     

    Thanks,

    Arun.

  • Arun ,

    Thanks for the info. If i have understood correctly the code snippet pointed by you will help me to programm an I2C based EEPROM with the required botoloader and boot configuration tables to boot from a desired mode (SPI,Ethernet.PCIe e.t.c) via the I2C EEPROM. i.e. on power on by default the code in the I2C EEPROM gets executed which inturn copies the code from an external memory(ex.SPI) to the DDR, depending on the boot mode setting and the boot configuration table programmed on the EEPROM. Please correct me if i am worng.

    I am looking at a scheme wherein , on power on the control jumps directly to an external memory. For example , if i place the secondary bootloader and boot parameter tables on an SPI based NOR Flash and set the boot mode pin settings for SPI boot mode (BOOT[2:0] = "110" : SPI) i would expect the bootloader on the NOR Flash to execute.Will i be able to achieve this functionality. I intend to put the PLL fix in the code sitting on the NOR Flash.

    If the above scheme is possible ,what modifications should i do in the EVM to achive this. I believe that EVM supports only booting via I2C :

    -NOR boot via IBL over I2C

    -NAND boot via IBL over I2C

    -EMAC boot via IBL over I2C

    Also the EVM provides applciation to write boot configurations to I2C based EEPROM on board (Step 2 "Programing "IBL Configuration"" in the file "evmc6678-instructions.txt" present under ../bootloader/ibl/docs

    Steps to use IBL on the c6678 EVM

    1. Programing "IBL" on the EEPROM at bus address 0x51
       (a) Use the I2C EEPROM writer for c6678 EVM from the MCSDK distribution.
       (b) Program i2crom_0x51_c6678_le.dat (IBL image) to the EEPROM at I2C BUS
           address 0x51 following the EEPROM writer's procedure.

    2. Programing "IBL Configuration"
       NOTE: For an understanding of the IBL configuration parameters used in this step,
             please refer to the IBL-Configuration documentation. The configuration
             data structure is ibl_s.  
       (a) Make sure that the boot mode dip switch is set to no boot/EMIF16
           boot mode on the EVM (please refer to the EVM technical reference manual
        on how to set the boot mode dip switches.
       (b) Open CCSv5 and launch the evmc66xx emulator target configuration and connect to core 0.
       (c) Load the program i2cparam_c6678_le.out to CCS.
       (d) Run the program and a message "Run the GEL for the device to be configured,
           press return to program the I2C" will be printed on the CCS console.
       (e) Load i2cConfig.gel (in CCSv5 Tools->GEL Files, right click mouse in GEL Files
           window and select "Load GEL"
       (f) Run the GEL script "EVM c6678 IBL"->setConfig_c6678_main, this will set the
           default boot parameters for booting application images from NOR, NAND and
           Ethernet.
       (g) Now press "Enter" in the CCS console window, and the program will write the
           boot parameter table to the EEPROM. On success the message "I2c table write complete"
        will be printed on the CCS console.

    3. Programming the application on NAND or NOR flash
       NOTE: This step is not needed if the application is booted from Ethernet.
       (a) Use the NAND or NOR writer c6678 EVM from the tools directory.
       (a) Flash the Application to NAND or NOR. For instructions please follow
           the instructions given along with the NAND/NOR writer.

    4. Booting the Application using IBL
       Supported boot modes:
       IBL supports three I2C boot modes: NOR boot, NAND boot and EMAC boot.
       Both NOR boot and NAND boot support maximum 2 images, EMAC boot supports only 1 image.
       For all the I2C boot modes, user needs to set the boot dip switches to I2C master, bus address 0x51.

       NOR Boot:
       Set the dip switches (pin1, pin2, pin3, pin4) to:
        SW3(off, off, on, off),
        SW4(on, on, on, on),
        SW5(on, on, on, off),
        SW6(on, on, on, on)
       This will set the boot para index to 0 to boot the NOR image, by default
       the boot configuration table sets the NOR offset address to be 0 and
       image format to be ELF for image 0.
      
       NAND Boot:
       Set the dip switches (pin1, pin2, pin3, pin4) to:
        SW3(off, off, on, off),
        SW4(on, off, on, on),
        SW5(on, on, on, off),
        SW6(on, on, on, on)
       This will set the boot para index to 2 to boot the NAND image, by default
       the boot configuration table sets the NAND offset address to be 16384
       (start of block 1) and image format to be BBLOB for image 0.

       EMAC Boot:
       Set the dip switches (pin1, pin2, pin3, pin4) to:
        SW3(off, off, on, off),
        SW4(on, on, off, on),
        SW5(on, on, on, off),
        SW6(on, on, on, on)
       This will set the boot para index to 4 to boot an image from a remote TFTP
       server, by default the boot configuration table sets the server IP to be
       192.168.2.101, board IP to be 192.168.2.100 and image format to be BBLOB.

     If i have to achieve a boot from SPI based NOR flash directly , i would have to load the boot configurations to the SPI NOR Flash. Is there a similar applciation avaliable to load the boot configurations onto the SPI based NOR Flash on board ?

    -Anil

     

  • Anil,

    Let me see if I can help.  There's a lot of info here, but I want to make sure I understand your REAL problem.  Reading the thread it would seem you are ultimately trying to boot the 6678 from a single flash device, i.e. you do not want to purchase/populate multiple flash devices.  Is that correct?  If so, yes, you can definitely achieve this goal.  The way you go about doing this will vary slightly depending on the type of memory (i.e. depending on the boot mode).  That said, you have referenced all kinds of memory in this thread.  Please choose one, i.e. what is your preferred nonvolatile memory to use in this device?  Once we narrow this down to a single mode we can move forward in terms of how you actually boot.

    Brad

  • Hi Brad,

    Yes, your assumption is correct . We intend to have a single flash on our system and we would like to boot the system directly via this flash i.e. without using an I2C EEPROM. To be more specific , we intend to populate an SPI based NOR flash on our system. We are planning to use the same part that has been mounted on the eval kit (N25Q128A21BSF40F).

    We would like to know if this is possible .

    -Anil

  • Yes, you can boot directly from SPI flash.  This is discussed in Section 3.6 "SPI Boot Operation" of the 66x Bootloader User Guide.

  • Hi Brad ,

    Thanks for the info. I understand that this option (booting directly from SPI based NOR flash) is not supported in the EVM. Please confirm.

    If so, is there a way we can test this on the EVM ? What modification are to be done in hardware/software with respect to the EVM to support this ?

    The EVM that i am referring to is the TMSDXEVM6678L Rev 0.2 and software package is BIOS MCSDK 2.00.00 (BETA2).

    -Anil

  • maril said:
    I understand that this option (booting directly from SPI based NOR flash) is not supported in the EVM. Please confirm.

    It looks like the examples provided in the MCSDK are based off I2C boot.  I see absolutely no reason why you cannot boot directly from SPI flash though.

  • Anil/Brad,

    The SPI boot from NOR is indeed supported directly. But since the PLL lockup issue exsist in Shanon, the EVM designer has programmed the FPGA in such a way that no matter what boot you set in the boot pins, the DSP boots in I2C runs the IBL fix for the PLL issue and then re-enters the boot ROM based on the boot mode set in the pins. So if you want to use SPI, please go ahead and set it in SPI boot and boot the board.

     

    Thanks,

    Arun.

  • Arun ,Brad,

    Thanks for the details .

    Arun ,

    From this I understand that it is possible to achieve boot directly from SPI memory using the following steps :

    1) Load the bootloader file  to SPI memory using the NOR Flash writer appliaction provided in the MCSDK package. (This bootloader file will contain the PLL workaround code)

    2) Load the Appliaction file to SPI memory using NOR Flash writer appliaction provided in the MCSDK package.

    3) Change the boot mode switch settings to SPI boot .

    4) Power ON the board.

    Please confirm.

    -Anil

     

     

  • maril said:

    From this I understand that it is possible to achieve boot directly from SPI memory using the following steps :

    1) Load the bootloader file  to SPI memory using the NOR Flash writer appliaction provided in the MCSDK package. (This bootloader file will contain the PLL workaround code)

    2) Load the Appliaction file to SPI memory using NOR Flash writer appliaction provided in the MCSDK package.

    3) Change the boot mode switch settings to SPI boot .

    4) Power ON the board.

    Please confirm.

    Correct.

  • Hi Anil,

    I'm starting working on the C6678 EVM and I want to check the SPI NOR flash boot option, have you succeeded with doing this?

    Thanks,

    HR

  • Hi ,

    I have not got a chance to test this scheme.

    Please let us know your findings when u have finished the testing.

    -Anil

     

     

  • Hi Brad,

    I'm trying to use the SPI for the C6678 EVM currently I succeeded with the SPI Nor flash boot as the secondary boot to the I2C (MCSDK demo),

    - How can I load the first (with the PLL workaround) & second boot on the SPI NOR flash?

    - How do I set the second boot start load address?

    - What should be the SPI boot mode device configuration description for the EVM?

    Thanks,

    HR

  • You can use the example in the external wiki page for secondary boot after PLL fix. Right now it has only for SRIO, Ethernet and PCIe, but it is easy to upgrade it to boot through SPI. Only thing you need to change is the DEVSTAT value to accomodate SPI. The link for TI external wiki is below:


    http://processors.wiki.ti.com/index.php/C66x

     

    Thanks,

    Arun.

  • Hi Arun,

    Yes, I have seen this example, as I need to put both SW on the same device (NOR flash) where do I define the second boot starting address? I assume it should be part of the first boot,

    Thanks,

    Haim

  • Hi Arun,

    - Is there an example for downloading all the cores with different SW, how do I define the boot table?

    - Where can I find the structure of the boot table?

    Thanks,

    HR

  • Hi HRI,

    The boot starting address will be in the SW. The boot table that you are loading will have the start address in the start. PLease refer to the boot table process.

     

    Thanks,

    Arun.

  • Yes we do. Please check SRIO boot example in MCSDK. The bootloader UG has a description for boot table format.

     

    Thanks,

    Arun.

  • Hi Arun

    OK, booting one core is working fine - 
    - Writing the ibl structure to the I2C eeprom
    - Compiling my program
    - Flashing the out file to the NOR flash
    - Setting the board switches to SPI boot and resetting the board
    Now I want to load two different out files one to core "0" and the second one to core "1", how can I combine the two out files (I'm using global address for the L2)? What should I change in the ibl?
    Thanks,
    HR

  • Hi HR,

    Sorry for the  delay. MCSDK has a example for multicore boot. Check under utils->boot_loader->examples->srio

     

    Thanks,
    Arun.

  • Hi Arun,

    OK, I have checked the SRIO but I think that I need a different way for the SPI boot, can I do the follow - 

    - Generate the boot table for each out file with the hex6x

    - mearge the boot tables with the mergebtbl

    - Convert it with bconvert64x

    - Convert to CCS file with b2ccs

    - Generate the complete SPI image SPI parameters + boot table with myparser

    Is this correct? what should be the ibl.bootModes[0].u.norBoot.bootFormat ? currently it is define to = ibl_BOOT_FORMAT_ELF

    Thanks,

    HR

  • It seems correct except you missed one step in between. I2C and SPI uses the same data encapsulation. So use this order.

     

    hex6x core0.rmd

    hex6x core1.rmd

    hex6x core2.rmd

     

    mergebtbl core0.btbl core1.btbl core2.btbl simple.btbl

     

    bconvert64x -le simple.btbl simple.btbl.be

    b2i2c simple.btbl.be simple.btbl.i2c

    b2ccs simple.btbl.i2c simple.i2c.ccs

     

    myparser simple.i2c.ccs i2cconfig.txt i2cromfara.ccs

     

    Thanks,

    Arun.

     

     

     

     

     

     

     

     

  • Hi Arun,

    - What should be the starting add for the ROM1: org address in the rmd file?

    - Is there an spiconfig,txt file?

    - What sw can I use to download the SW to the SPI nor flash?

    Thanks,

    HR

  • The rmd file should be same as I2C.

     

    Thanks,

    Arun.

  • Hi Arun,

    I tried to run the post_romparse.bat file under the mcsdk_2_00_03_15\tools\post\evmc6678l\bin and I'm getting the error - 

    "bconvert64x: Unspecified error, line 667"

    Have you tried it?

    There are two hex6x in the file what is it for?

    "hex6x -order L post_image.rmd post_evm6678.out

    b2ccs post.b post.ccs

    hex6x -order L post.rmd ..\post_evm6678.out

    bconvert64x -le post2.b post.b"

    Thanks,

    HR

  • Hi Arun,

    Have you had the chance to check the post boot issue (bconvert64x)?

    Thanks,

    HR

  • Hi Aril,

    Have you succeeded with the C6678 SPI boot?

    Thanks,

    HR

  • Sorry I was out of country for couple of weeks. I can check tomorrow and let you know.

     

    Thanks,

    Arun.

  • Hi Arun,

    Have you had the chance to check it,

    Many Thanks,

    HR

  • Hi HR,

    Are you using CCS5.0.3 or CCS5.1 compiler tools. With CCS5.1 I am having different set of probelms and the developer suggested me to use only 5.0.3.

     

    Thanks,

    Arun.

  • Hi Arun,

    I'm using CCS5.1, what are the issue with using CCS5.1? will there be a version for CCS5.1?

    Thanks,

    HR

  • It seems the compiler tools they have in CCS5.1 is not compatible with the utilities.

     

    Thanks,

    Arun.

  • Which compiler version is recommended?  We can use any compiler version we want in CCS 5.1...

  • I am sorry. I am actually talking about the tools executable that we have in the CCS code base folder not the CGT.

     

    Thanks,

    Arun.

  • Hi Arun,

    - What is the CCS code that influence the files isn't it an IDE, we can use an external make file will this be an issue as-well?

    - I have run the batch file post_romparse.bat at mcsdk_2_00_03_15\tools\post\evmc6678l\bin which used the out file that comes with the MCSDK sw,

    - I got the below warnings for the first hex6x,

    ***********************************************************************************************

    C:\TI_CCS5.1\ccsv5\tools\compiler\c6000\bin\hex6x -order L post_image.rmd post_evm6678l.out

    Translating to ASCII-Hex format...

       "post_evm6678l.out"   ==> .text

    warning: section post_evm6678l.out(.text) at 0830000h falls in unconfigured

       memory (skipped)

       "post_evm6678l.out"   ==> .const

    warning: section post_evm6678l.out(.const) at 0843640h falls in unconfigured

       memory (skipped)

       "post_evm6678l.out"   ==> .cinit

    warning: section post_evm6678l.out(.cinit) at 0843bech falls in unconfigured

       memory (skipped)

    ***********************************************************************************************************

    - After changing the length in the post_image.rmd from 0x10000 to 0x30000 I'm getting the below

    ***********************************************************************************************************

    C:\TI_CCS5.1\ccsv5\tools\ompiler\c6000\bin\hex6x -order L post_image.rmd post_evm6678l.out

    Translating to ASCII-Hex format...

       "post_evm6678l.out"   ==> .text

       "post_evm6678l.out"   ==> .const

    warning: section post_evm6678l.out(.const) was padded by 2 to a size of 920 to

       satisfy the specified memory width of 4

       "post_evm6678l.out"   ==> .cinit

      ****************************************************************************************************

    - Where can I find the yyparse() function in the romparse.c file

    - Is there post_i2crom-map.pp for the SPI?

    Thanks,

    HR

  • Hi HR,

    The YYPARSE function is in a rparse.tab file whihc is not added in the utils. i will talk to the dev team and understand that. We don't have the map file for SPI. This was just a warning. Did you try the image by loading in SPI?

     

    Thanks,

    Arun.

  • Hi Arun,

    I assume you mean to load post_i2crom.dat to the SPI flash, can I convert the dat file to a bin file,

    Please let me know if there is any update regarding the YYPARSE,

    Thanks,

    HR

  • Hi Arun,

    Can I use the writer for downloading the post_i2crom.dat file to the flash?

    Where can I find explanation regarding the first part of the dat file - 

    1651 1 10000 1 2cb2

    0x00400000

    0x00280000

    0x00100002

    0x00010400

    0x00500000

    0x00010271

    0x00c80000

    Thanks,

    HR

  • Hi HR,

    The first line is the CCS header. The only thing you care about is the last variabe in it. it is the size of the data that follows including the checksum for the blocks. You can use the writer to load this into the SPI. I am trying myself today. I will let you know what happens.

     

    Thanks,

    Arun.

  • Hi Arun,

    I download the post_i2crom.dat file to the NOR flash using the writer but it didn't worked, I downloaded the post_evm6678l.out file and it's working correctly, have you tried to download the post_i2crom.dat?

    In the post_romparse.bat the first two lines are generating post.ccs which is not used in the rest of the batch file, why is that?

    Thanks,

    HR

  • Hi Arun,

    Any update?

    Thanks,

    HR

  • Did you use the nor writer?

     

    Thanks,

    Arun.

  • Hi Arun,

    Yes, I used the nor writer, the code has verified the content but the sw doesn't work, 

    Have you tried it?

    Thanks,

    HR

  • Yes we have tried it. but a while ago and I see some instructions are changed. let me confirm from the team and get back to you.

     

    Thanks,

    Arun.

  • Hi Arun,

    Any update?

    Thanks,

    HR

  • Hi Arun,

    Any update? are there issues that prevent you to test it? are you going to test it?

    Thanks,

    HR

  • Hi HR,

    it worked for me. I am going to try the new release today and reply to you. Give me couple of hours.

     

    Thanks,

    Arun.

  • Hi HR,

    I am missing something in the latest release. I am working with team and will keep you posted.

     

    Thanks,
    Arun.

  • Hi HR,

    Seems like the nor writer in the MCSDK might not be useful to boot through SPI. i am getting a project to write into SPI. I am going to check tomorrow and attach in the post if I succeed.

     

    Thanks,

    Arun.

  • Hi HR,

    Sorry for the delay. Attached is an examle simple_le.dat file which you can use as a reference. Also the bat file attached is the list of utilities used to get the dat file. One new executable is the byteswapccs. I also attached the .c file which you can compile using GNU c compiler. One problem is for some reason the read_addr_msw is by default sets to 0x51. Please hard code it to 0x0. I am trying to debug this issue and will release the official version with the fix soon. As we discussed offline, I also found an error in the boot parameter structure for the SPI. The correct order is give below. We will soon get the updated ug.

     

    length 40
    checksum 0
    boot_mode 50
    portNum 0
    swPllCfg_msw 0
    swPllCfg_lsw 0
    options 0
    addrWidth 24
    nPins 4
    csel 0
    mode 1
    c2tdelay 1
    cpuFreqMhz 800
    busFreqMhz 0
    busFreqKhz 500
    read_addr_msw 0
    read_addr_lsw 0
    next_csel 0
    next_read_addr_msw 0
    next_read_addr_lsw 0

     

    Thanks,

    Arun.3201.SPIBoot.zip