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.

C6670 SPI boot from another NOR FLASH address,how?

We want to implement a double image solution when use SPI boot, in case one image damaged we can also boot from another image.

1. Now i can sucessfully boot in the SPI boot mode,for a NOR flash.

2.The NOR FLASH is 16M capacity, now my normal image is about 5MB.

3.In some cases,when the customers update the FLASH image, the image may have some prombles,the image maybe damaged and can't boot  then.

4.so we want to have another backup image burnt into the NOR FLASH, in the last 5M NOR flash space.

5. when the first image is in the front 5MB is damaged and the the DSP can not boot,then we can change the  the boot GPIO pin states(conresponse to DEVSTAT-BOOT MODE) to config another boot parameter table to boot from another NOR FLASH address,where we have burned a backup image into,then the DSP can boot again.

In my understanding, i have to append another paramter table into the image,and the paramter table must indicate to the other Boot table address instead of 0x400,am i right?

but I don't know how to use the utilities to make all those works.

1.How to append another parameter table,which indicate another boot address?

2.How to build the other backup image?should I keep the first 0x400 as the boot parameter space also?

Give me an example,please, because the TI bootloader documents said nothing! 

  • Hi Frank,

    You have to use IBL for such implementations. The above requested is already demonstrated using EVM.

    Boot Mode - Offset

    DIP SW3

    (Pin1, 2, 3, 4)

    DIP SW4

    (Pin1, 2, 3, 4)

    DIP SW5

    (Pin1, 2, 3, 4)

    DIP SW6

    (Pin1, 2, 3, 4)

    IBL NOR boot on image 0 (default) - 0x0 (off, off, on, off)1,2 (on, on, on, on)3 (on, on, on, off)4 (on, on, on, on)
    IBL NOR boot on image 1 - 0xA00000 (off, off, on, off) (off, on, on, on) (on, on, on, off) (on, on, on, on)

    Hardware Setup Guide:

    1. Set the Boot mode to "No Boot" mode


    2. Program and configure the IBL. Refer below link,

    3. Use NOR writer to load the application on to NOR flash.

    4. Set the boot mode to "IBL NOR boot".

    Thank you.

  • Hi Frank,


    As Raja mentioned, the scheme that you are trying to implement has been demonstrated with the help of a secondary boot loader like IBL that can be used to create the switch to boot 2 different images based on a GPIO setting.  The bootROM also supports this scenario as I have tried to demonstrate in the diagram below:

    For this you will need to format the flash image to have the parameter table arranged on after the other at the start of SPI and populate the dev addr in each of the parameter table apappropriately to point to the start of each of you boot images. The romparse allows you to speicfy 2 parameter tables and specify to boot image files in the spirom.map file to create the entire image using single shot. I will try to look if we have some sample test code for you to test this scheme and get back to you.

    Regards,

    Rahul

  • Rahul, thank you so much for help me! I need your help!

    we have already implement the Scenario 1 your showd above on our products in ROM SPI MODE. I am afraid there is no need to use IBL boot mode. ROM SPI mode is simple, not only to the hardware but also to the software implementation. Futher more, I am not familiar with IBL boot at all, and our hardware had sold to the customers and can not be modified.

    "The romparse allows you to speicfy 2 parameter tables and specify to boot image files in the spirom.map file to create the entire image using single shot", yes, this is the problem.

    1. How to config the .map file to append two parameter talble each specify to different boot table?
    2.How to combine 2 boot images which located to different address into ONE finally .bin file?
    3.This is no documents describe how to use the utilities. We can ONLY rely on your example each time when we want to make a little change. can you send me all the utilities and the the documents which describe the detail use guide of them ?
    we may be told there is source code in MS_SDK.
    But, first, there are not enough utilities; second, no documents to guide to use them.

    PS,for example,
    --Romparse?how to config the .map file? (1)NO DOCUMENT! (2)the input parameters in .map file(from an example which you provide sometimes ago) can't be found the the romparse source code in MS-SDK.So I don't know if the example ".map" file is for 6670, and without your example ,I cant configure any new parameters or change any parameters when I need to do so.
    --mergebtbl.exe ? No document and source code.
    --hex6x spiboot.rmd ? No documents and source code.
    --byteswapccs? No documents and source code.
    --b2i2c/ b2ccs / ccs2bin? No documents.

    We get confused and helpless without all the above materials, which is essential when we develop the products.
  • 2.How to combine 2 boot images which located to different address into ONE finally .bin file?

    We do not have such utilities.

    3.This is no documents describe how to use the utilities. We can ONLY rely on your example each time when we want to make a little change. can you send me all the utilities and the the documents which describe the detail use guide of them ?

    we may be told there is source code in MS_SDK.

    But, first, there are not enough utilities; second, no documents to guide to use them.

    Please refer the How_to_boot_C6678_from_SPI_NOR.doc from below attachment for usage of utilities.

    6404.KeystoneI_bootloader_workshop.zip

  • PS,for example,

    --Romparse?how to config the .map file? (1)NO DOCUMENT! (2)the input parameters in .map file(from an example which you provide sometimes ago) can't be found the the romparse source code in MS-SDK.So I don't know if the example ".map" file is for 6670, and without your example ,I cant configure any new parameters or change any parameters when I need to do so.

    --mergebtbl.exe ? No document and source code.

    --hex6x spiboot.rmd ? No documents and source code.

    --byteswapccs? No documents and source code.

    --b2i2c/ b2ccs / ccs2bin? No documents.

    --Romparse?:

    Romparse is used to append the boot parameter to a boot table or a boot configuration table. The source code is avialble in MCSDK. Please refer (..\ti\mcsdk_2_01_02_06\tools\boot_loader\ibl\src\util)

    --hex6x?:

    Hex6x is used to convert the application code into a boot table format.  Please refer below document for usage.

    --byteswapccs?:

    Used to convert the application from little endian to big endian format.

    --b2i2c/ b2ccs / ccs2bin?: The source code is avialble in MCSDK. Please refer (..\ti\mcsdk_2_01_02_06\tools\boot_loader\ibl\src\util)

    Boot table format convert it into the i2c/spi format by passing through the b2i2c(ascii hex i2c data file).

    The i2c/spi based format of the application table convert it into the CCS acceptable .dat format using b2ccs(Convert a hex b file into a ccs data file).

    Convert a ccs file to a raw binary file.

  • Thank you for your reply.

    I know the general purpose of the utilities above.

    But still I dont know how to invoke them.

    It is similar to tell me "C is a program language" and no more details are informed.How can we use it?

    There should have docs to tell the detail usage of all the utilities.But not in a online ask-answer mode.Sadly, untill now,there is no docs to tell the detail usage of any utilities at all, only the general purpose described.For example, without the example of romparse, only the God knows how to invoke it ! only the God knows there should be a “.map” file for invoke; only the God knows how to construct the “.map” file ;only the God knows the name of each parameters in the ".map" file. only the god knows how to specify more parameters in the ".map" file which are not included in your example “.map” file. 

    There should have documents to tell the detail usage of utilities!  @TI.com

  • Hi Rahul,

    I need your help, thanks in advance!

    when I invoke the romparse to append the parameter table 2, I failed to change the boot image table addr in ".map" file.

    I think the "dev_addr"  would work, but it doesn't. The romparsed address is always 0x400!

    Can you tell me how to config the ".map" file to specify the start address of boot Image 2?

    I  am waiting for your example.

    There are always mistakes on TI documents, so if you have an answer from your documents, please have a test to verify it first and then inform me.Thank you so much!

  • Hi Frank,

    I am checking on this with the BootROM author. We don`t seem to have a 2 boot image example but we do have an example to boot images from an alternate location using "dev_addr" but it was created for a different device in the keystone family. I will modify the example and give you guidance on how to modify the dev_addr once I have the modified example code.

    The reason for the 0x400 dev_addr that you are seeing is that romparse in MCSDK accounts for up to 8 parameter tables (each of size 0x80).This field is populated only for the I2C boot usecase and not for SPI boot paarameter table.We will need to modify romparse to make it possible to not reserve space for unused tables and to modify the read_addr_msw and read_addr_lsw field from the dev_addr specified from the map file after that it should work. We don`t support this custom case with romparse in MCSDK so you will need to modify the utility to place the parameter tables in that order and update the read_addr fields from the map file. 

    Check the code in the switch statement in romparse.c

    case DEV_ADDR: current_table.i2c.dev_addr = value;
    break;

    Try changing this to

    case DEV_ADDR: current_table.spi.read_addr_msw = value >> 16;
    current_table.spi.read_addr_lsw = value & 0xffff;
    break;

    We will need to modify romparse to make it possible to not reserve space for unused tables, after that it should work. We don`t support this custom case with romparse in MCSDK so you will need to modify the utility to place the parameter tables in that order. 


    Regards,
    Rahul

  • Hi Rahul,
    Thank you so much!

    I can change the code you pointed out in romparse.c, but I don't know how to build the code to generate the romparse.exe. I didn't find any clear guide docs describe how to build the utilities.

    Can you tell me how to build the utilities step by step?
    Thank you in advance!
  • Hi Frank.

    The utilities need to be built using MinGW for Windows with msys , gcc and make tools installed for your Windows host machine. Instructions to build the IBL package is provided in mcsdk_2_xx_Xx_Xx/tools/boot_loader/ibl/doc/build_instuctions.txt.

    You can invoke make from the tools/boot_loader/ibl/src/make in the MCSDK after setting up the paths using setupenvLnx.sh and setupenvMsys.sh and then invoke make from that directory with your target specific options. If you don`t want to build the entire ibl package, simply chnage directory to ibl/src/util/romparse directory and invoke make using

    make TARGET=C66x ENDIAN=little I2C_BUS_ADDR=0x51

    Hope this helps.

    Regards,
    Rahul
  • Hi Rahul Prabhu,

    Long time no see and I am still work on the backup image.

    I have sucessfully test the 2 image boot meathod by switch the GPIO pin level, and then I can boot from one of the two image burned in the FLASH.

    But there is a problem, the GPIO pin  level of the hardware is FIXED in our earlier products.

    So I have got an idea to modify the DEVSTAT register and then reset the chip to re-boot from another image.

    Have you got my idea? Below is the key point:

    It's about RESET and DEVSTAT latching.

    Look, the datasheet :for hard reset and soft reset,the DEVSTAT pins are not re-latched. and the boot mode field is writable(I have verified), so I can modify the boot configuration field in DEVSTAT,and then reset.

    But i found  both hard and soft reset,the DEVSTAT is re-latched !  It is not acting as the Datasheet descripts.

    Can you tell me why?

    Here is my code:

    {

    ...
    ...

    CSL_BootCfgUnlockKicker();
    /***************MODIFY DEVSTAT*******************************************/
    //modify DEVSTAT for next re-Boot
    volatile uint32 *RegPtr;
    RegPtr = (volatile uint32*)0x02620020;
    *RegPtr = 0x0003964D; //on POR the value is latched as 0x0003960D


    /***************BELOW FOR RESET******************************************/
    //RSTCTL Key
    RegPtr = (volatile uint32*)0x023100E8;
    *RegPtr ^= 0x00005A6A;

    //RSTCFG set softreset
    RegPtr = (volatile uint32*)0x023100EC;
    *RegPtr |= 0x00003000;//also tried hard reset,the value will be 0x00000000

    //RSTCTL Key
    RegPtr = (volatile uint32*)0x023100E8;
    *RegPtr ^= 0x00005A6A;

    //RSTCFG trig softreset
    RegPtr = (uint32*)0x023100E8;
    *RegPtr &= 0xFFFEFFFF;// sadly, after reset ,the DEVSTAT re-latched to value 0x0003960D
    CSL_BootCfgLockKicker();
    ...
    ...

    }

  • Updated the new thread. Please check.

    e2e.ti.com/.../1678767
    Thank you.
  • Hi Frank Deng,

    There is a litbug in Parameter Table Index description SPI boot,

    It should be,

    6-5 - Parameter Table Index.

    4-3 - Reserved.

    Please refer below thread,

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

    Thank you.

  • Raja said:

    Hi Frank Deng,

    There is a litbug in Parameter Table Index description SPI boot,

    It should be,

    6-5 - Parameter Table Index.

    4-3 - Reserved.

    Please refer below thread,

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

    Thank you.

    Hi Raja,

    Already noticed months ago.We have confirmed this in ROM source code.
    I have to complain about the bad documentation. That is toooooooooo bad, especially for bootloader. "LITTLE bugs"  wasted us a lot of time!
    However, it seems to become worse and worse. :(
    :(

    Maybe that is the value where TI E2E employees here be.

  • Hi Frank,

    We have similar requirement of selective Booting from one of two boot images in SPI NOR flash. We have access to GPIOs.
    It will be great, if you can share how you have solved the problem. can you share the steps you have done for combining two images and porting combined one into single SPI NOR.

    Thanks in advance,

    Ashok.M