We are facing a problem, when we store the codes in L2SRAM by bootloader, the program runs smoothly.
When we store the codes in L2SRAM by JTAG, the program runs smoothly.
When we store some of the codes in DDR3 by JTAG, the program runs smoothly.
But when we store some of the codes in DDR3 by Bootloader, the core get abort when first calling the funtion stored in DDR3. Our codes are getting bigger and bigger, we should put some of the codes in DDR3.
We are using TMSC6670 SPI norflash boot directly(no IBL, not EVM)on our board. And Rahul gave us a reference named "SPIboot_ddr.zip", and I think that the reference is for TMSC6657 DSP, please look at
The emif4config table doesn't have a chipConfig array.
C:\ti\mcsdk_2_01_02_06\tools\boot_loader\ibl\src\device\c66x\tiboot_c665x.h (the same as tiboot.h in "SPIboot_ddr.zip")
The emif4config table has a chipConfig array.
So, I think C6670 and C6657 are using different bootloaders, and the "SPIboot_ddr.zip" is completly for C6657.
The problem is, in our situation, how could we config the chipConfig array acorrding to our TMSC6670 bootloader? Hoping to your reply, thank you.
Please refer to my response on the following thread
Yes, the DDR configuration table is different for the two devices so you will need to use the DDR configuration table from the file tiboot_C6670.h from the MCSDK to initialize the DDR. If there are certain parameters that are not part of the DDR configuration table, you may need to design a two stage boot as I have described in the e2e thread given above.
In reply to Rahul Prabhu:
Thanks for you reply. I have read the http://e2e.ti.com/support/ dsp/c6000_multi-core_dsps/f/639/t/298106.aspx link post and the "reboot.c" file that you gave to me. But I still have couple questions waiting for your answers.
1. I read the "romtBootReentry ()" funtion in "reboot.c" and I couldn't find what it did in the funtion. Where could I find the defination of the funtion "romtBootReentry ()" ?
2. According to our project, we have a DDR_Config() funtion at the beginning of main(). So I have an idea, if I don't want to design a two stage boot, I wonder if we could just insert the romBootReentry() funtion after the DDR_Config() funtion and make sure the romBootReentry() executive once, or it would fall into an endless loop? What do you think about this? And as you know, is there any way to make sure the romBootReentry() executive just once that make sense?
3. According to our project, since Core1 to Core 3 runs smoothly when some of the codes store in DDR3. So, I wondered if I could assume that when the ROM Bootloader is copying codes to DDR3 from L2 without configureing the chipConfig array(C6657's ROM Bootloader has this part), the DDR3 works correctly. If we change the DDR3 settings to that statue when we running our program, can we run the program smoothly without configureing the chipConfig array? In this situation, what is the DDR3 statue when the ROM Bootloader is copying codes?
Looking forward to your reply.
In reply to Karlphy Fong:
About Question 1.
I think all romtBootReentry () does is just set the PC to romtBootReentry ()
(_romtBootReentry = 0x20b00008;)
in order to jump back to the begining of the RBL code.
In reply to ilay nissim:
I spoke to a DDR expert on the team and it appears DDR3 chip config registers provide the seed values for DDR3 leveling which is necessary for proper DDR3 functionality. However, you can still get functional DDR without leveling at low speed bins like DDR-800, so for boot purposes those registers might not matter.
We have ran test on C6678 without touching either the DDR Config registers or the RDWR_LVL_RMP_CTRL and RDWR_LVL_CTRL registers. Can you try to boot with DDR enabled by using a DDR-800 configuration and let us know if you are able to boot the device.
ROM re-entry address is 0x20b00008 (look for the symbol _romtBootReentry in the map file).
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.