IBL - load time issue

Hi Aymeric,

Here are my answers

We would like to try some workarounds as it is done in the IBL for the EVM. I have a few questions that I hope you can help me with

1) We want to run from SPI rather than EE2ROM (a bit faster), Can I compile the IBL (without the part checking the FPGA registers) and generate an image that can run from the NOR flash?

<AVM> Yes you can do it. The procedures for compiling IBL is in the MCSDk package. The SPI boot example is in the e2e post link below:

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/115298.aspx?pi70912=4

2) Do you have a manual (or application note) on how to generate a bootable (bin) image from a file generated in CCS (*.out)? I assume I can use the NOR writer example to write to the NOR afterward.

<AVM> See the link provided above.

3) How do I debug your IBL from CVS? I have tried to load ibl\src\make\bin\i2cparam_0x51_c6670_le_0x500.out but the starting code try to rewrites to the EPROM fails and corrupts it. Loading the out files from ibl\src\make\ibl_c66x\ but it does not work.

<aVM> You can run the IBL code from CCS and step through it.

4) there are 2 main in the IBL code. One is in iblInit.c and one in iblMain.c. It seems that there are two pieces of code that are built. How do they work out together?

<AVM> I don't know much details on code. But since we have the source provided to you, you might be able to skim through it to understand. Please let me know if you geet stuck somewhere .

Thanks,

Arun.

Arun

Thanks for the answers. I saw that you are the expert on the boot loaders as your name is associated on all the bootlader queries.

I will get back to you regarding point 1 and 2 but yes, I am stuck on point 3 and 4 and this is why I asked the questions.

There are some confusing points with the 2 "mains" and I am not sure how they are built and run. I have the source which is helpful but I missing the understanding of the end part => how is the compiled code assembled into the device (EEPROM or spi).

I know I can load the code from CVS and run through it BUT I try to step through the code it and it does not work (for me). Could you let me know the answer to point 3 please.

Aymeric

Arun,

I came with a set of question because I urgently need to have this part working. There are issues of POR with the C6670 that we must understand.

First let me tell you that the answers you provided are nothing like "support". Providing generic answers is not helpful. When someone comes with a specific problem, answering the specific questions is more productive. I wish you had sent me to an official application note as I asked rather than this post.

Regarding http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/115298.aspx?pi70912=4, you provided three different zip files that are doing completely different things. Even the makefile attached in 7853.simple.zip uses tools that are not even part of the MCSDK. Did you also notice that HR keep telling you that it is not working for her? And you keep telling, that it works for you?

Let me answer you why it works for you (and me on the EVM) because your EEPROM is still populated with the IBL. Did you try to clean your EEPROM and boot from "ROM SPI BOOT"? Did that work? => the answer is no.

Now, I have spent 2 days trying to do something that should be very simple and it still does not work. Do you think you can help?

the MCSK is provided with the following project: mcsdk_2_01_00_03\tools\boot_loader\examples\i2c\nor\evmc6670l\, I have modified it for you and for everyone that will read this query and have the same problem.6758.nor.zip

What is important about this project is that I wrote a script that does exactly the steps described in the post you sent me as a reference (bin\test\run_script.bat). I also provided in this project all the tools that are required: bin\utilities\. The "*.exe" were copied from the compilation of the IBL utilities using this command " make evm_c6670_i2c ENDIAN=little I2C_BUS_ADDR=0x51". You will notice that I added the byteswapccs.exe as it is not provided with the MCSDK.

In this directory you will find rmd file (taken from the IBL project which I believe is correct) and spi.map which I believe is used to build the boot parameter table described in section 3.6.1 of the bootloader user guide. This file is what you provided in the reference post. Looking at it I think it is not correct but this is your reference, I will ask questions about it after.

Steps required to run project:

1) import project in CCS and rebuild it

2) run the following command: \bin\copy.bat as the run_script needs a file called bootcode.out in the same directory

3) run_script.bat will do all the steps (described in your post) to generate spirom_le.dat

4) Use the NOR_writer to write the NOR flash (load dat file at 0x80000000 and run the writer)

5) set EVM in ROM SPI Boot and power on the board

It works, this is what we wanted to achieve. The boot mode extracted from DEVSTAT indicates that you booted from SPI and the serial terminal shows all the printout.

6) Delete the code in the EEPROM (IBL)

7) Power on your board again, nothing happens and the devstat indicated a bootmode of I2C.....

Note: I tried on our board where I do not have an EEPROM, no IBL and no FPGA and I got to the same point.

----------------------------------------

Questions:

1) On the EVM, is ROM SPI Boot really booting from SPI or is it also a mode where the FPGA will intercept the settings and force to boot from I2C, do the WorkAround and revert to SPI?

2) When I used the following command, " make evm_c6670_i2c ENDIAN=little I2C_BUS_ADDR=0x51", are the utilities provided working to make an I2C boot image or will they work to make an SPI boot image as well

3) In regard to the file spi.map, where I have the following section defined:

section {
  param_index    = 0
  boot_mode      = 50
 sw_pll_prediv = 5
 sw_pll_mult = 32
 sw_pll_postdiv = 2
 sw_pll_flags = 1

 options = 1
 core_freq_mhz = 800
 next_dev_addr_ext = 0x0
 c2t_delay = 0
 bus_freq_mhz = 0
 bus_freq_khz = 500
 addr_width = 24
 n_pins = 4
 mode = 0
 csel = 0
 exe_file = "boot_code.btbl.be.i2c.ccs"
}

a) The SPI Boot operation (section 3.6.1) advised that, bus_freq_mhz = 0 is by default 5 Mhz and bus_freq_khz is 0

b) are sw_pll_prediv = 5,  sw_pll_mult = 32,  sw_pll_postdiv = 2,  sw_pll_flags = 1 used to derive the SW PLL, MSW and LSW from the generic parameters (table 2.6 section 2.2)

c)how are Read address MSW and Read Address LSW generated

d) Using the utilities provided. the option set as 1 in the section, should it be 0?

Please Arun, let's work together on this issue are get it out of the way for both of us. I will have an answer and you will have a generic project to provide on next question on this issue.

Aymeric

Aymeric,

The reason why you cannot run with IBL is because the FPGA in the EVM. The FPGA always boots to the I2C no matter which boot you set. If you don't have the IBL in I2C, then you will never come out of I2C boot. This was programmed to solve a PLL issue. In your custom board, you can do it without going to IBL.

Also HR was able to get the boot working. Please see page 5 of the post. The problem was in the bootstrap setting and not the code. the example should work. I would recommend that you get the simple code attached in that post and load the .dat file using the NOR writer and see first if the SPI boot indeed works in your setup. Let us go from there.Please let me know if this first step works. I am more than willing to work on this with you. SO please send an update and we will proceed from there.

If you need any info on the first step too, please let me know and i can get you the code again in this post.

Thanks,

Arun.

Arun,

I sent you a zip file which is the simplest possible example. It does work on the EVM but does not work on my custom board (no FPGA, no EEPROM, no IBL)

Do you think we can work from this zip file and the process that is described?If you validate that I am using the correct utilities in the correct order and , then I have to think if spi.map is correct for my board.

I am interested in the answers to question 2 and 3 (the mode aspect) since you answered question 1.

Which utility generates the boot table?

Aymeric

PS: I am dedicated to get that work, anything you say will be tried straight away.

Arun,

Sorry, I will continue with the question about the previous post:

in the content of the post you provide this info:

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

and in the zip file you provide spi.dat with the following:

section {
  param_index    = 0
  boot_mode      = 50
 sw_pll_prediv = 5
 sw_pll_mult = 32
 sw_pll_postdiv = 2
 sw_pll_flags = 1

 options = 1
 core_freq_mhz = 800
 next_dev_addr_ext = 0x0
 c2t_delay = 0
 bus_freq_mhz = 0
 bus_freq_khz = 500
 addr_width = 24
 n_pins = 4
 mode = 0
 csel = 0
 exe_file = "boot_code.btbl.be.i2c.ccs"
}

I am confuse, how does the first part applies to the dat file or where is it used?

Aymeric,

The steps to follow to build the files are again in the post link I gave you. You should not do the bconvert64x. PLease fol;low the steps and see if that works.

I am attaching a sample map file which should also be there in the link.

section {
 boot_mode = 50
 param_index = 0
 options = 1
 core_freq_mhz = 1000
 exe_file = "spiboot.i2c.ccs"
 next_dev_addr_ext = 0x0
 sw_pll_prediv = 5
 sw_pll_mult = 32
 sw_pll_postdiv = 2
 sw_pll_flags = 1
 addr_width = 24
 n_pins = 4
 csel = 0
 mode = 0
 c2t_delay = 0
 bus_freq_mhz = 0
 bus_freq_khz = 500
}

One thing to note is that the romparse has a bug that it adds the 0x51 in the boot parameter for the dev_addr_ext. This should not be added. I need to debug the utility. But cannot get to it yet. You can manually change that to 0x0 after you got the bat file. If this step is not clear, please let me know.

Thanks,

Arun.

0)Could you comment on the previous post? I do not understand how you got these in the section of spi.map and I cannot locate them in any of the generated files.

length 40
checksum 0
boot_mode 50
portNum 0
swPllCfg_msw 0
swPllCfg_lsw 0

1)

Regarding the romparse, yes, this step is not clear. According to what I see when I compare the input and the output, romparse is adding a section of 256 lines (32 bit data). In this section added, there is no "51".2781.spirom.ccs

what you are calling the dev_addr_ext? is it an offset from start of memory? Am I using the correct tools?

2) the section you sent me is very similar to the one I am using. I do not think the order matters and if some fields are missing I guess they are defaulted by romparse.

3) using the script sent earlier and using bconvert64x worked on the EVM.... So this is strange but I will do what you say.

4) when loading the dat file to memory, I am choosing the option to use the fle header to set start address and size of memory block to be loaded. on the following page, I revert the start address to 0x80000000 as the NorWriter reads the memory.

5) ok, I am very confuse with the previous post. it seems that generating a bin file or a bat file needs two different method. This is from the post:

/**************************

Hi Arun,

Thanks, with this setting the bin files works (The batch file needs to be changed as there are a few additional lines which teir output is not used) while the dat files doesn't work, there are changes in the map file while the bin file uses an I2C params and the dat file uses the SPI params, Any reason for this?

The bin prepare file - 

- hex6x

- bconvert64x

- b2i2c

- b2ccs

- romparse

- ccs2bin

The dat prepare file (with changing the 0x51 to 0x0 in the dat file)- 

- hex6x

- b2i2c

- b2ccs

- romparse

- byteswapccs

***********************/

So if I go back to the 4617.zip, here is the order that utilities should be run:

..\utilities\hex6x -order L ..\utilities\boot_script.rmd bootcode.out
..\utilities\b2i2c boot_code.btbl boot_code.btbl.i2c
..\utilities\b2ccs boot_code.btbl.i2c boot_code.btbl.i2c.ccs
..\utilities\romparse -fill 0xff -rom_base 0 ..\utilities\spi.map
ren i2crom.ccs spirom.ccs
..\utilities\byteswapccs spirom.ccs spirom_le.dat

I though bconvert64x was required to Convert a hex6x boot table file into the format required by the c6x chip boot loader. Are you saying that hex6x provide the correct format straight away? The ibl is using this utility but generates a bin file as well. ok, I will try it out and get back to you soon.

----------------------

ok, I spent the afternoon trying on my board (not the EVM - No IBL) and nothing happens, neither from a bin nor from a dat.

Our board uses the same NOR than the EVM, it is on CS1 rather than 0 but it is the same. It does not boot. My devstat is 0x3150d. Little endian, SPI, parameter 0, chip select (it is a bit confusing if this is a bit mask or a number but looking at the EVM set up we set up 01 for the 2 bits) as CS1, 24 bit address, 4 pins (or hat 0 means since doc is wrong), mode1.

here is spi.data I am using to reflect that:

I really don't know what else to do

Aymeric

please, check my

Arun,

Is it possible to talk on the phone?

Aymeric

Hi Aymerric,

Regarding the map file, these are the first 12 byte offsets that are common for all boot modes. You can get this information from the boot loader UG.

Regarding the order of the utilities, the order is given below:

set IBL_UTIL=C:\MCSDK\mcsdk_2_1\mcsdk_2_01_02_05\tools\boot_loader\ibl\src\util
hex6x spiboot.rmd
%IBL_UTIL%\btoccs\b2i2c spiboot.btbl spiboot.btbl.i2c
%IBL_UTIL%\btoccs\b2ccs spiboot.btbl.i2c spiboot.i2c.ccs
%IBL_UTIL%\romparse\romparse nysh.spi.map
cp i2crom.ccs spirom_le.dat
byteswapccs i2crom.ccs spirom_le_swap.dat
%IBL_UTIL%\btoccs\ccs2bin   i2crom.ccs     spirom_le.bin
%IBL_UTIL%\btoccs\ccs2bin -swap i2crom.ccs spirom_le.swap.bin

You can use either the bin file or the dat file. The image (either in bin or dat format that you generate using the utilities above) can be loaded into the SPI using the norwriter. Again I believe that the NORwirtier is usable only with the EVM. I am checking to see if we need byteswap in all the cases.

Also I will get back to you on the romparse issue and will get you further information.

Thanks,

Arun.

Hi Aymeric,

The usage of byteswapccs depends on how the writer application loads the .dat or bin file into the SPI flash. If you take the .dat file, you can check that it is by default in big endian mode. Now the writer reads from MSB to LSB and writes in LSB to MSB, then the bytes are swaped. In order to get the value correct, you can use the byteswapccs to swap the bytes that is read.

Also you can add the bconvert64x utility to. Till this point I have configured the size of each of the section to be a multiple of 32, so i never used it. But if you have a section that is not, you need this utility. Also it doesn't hurt to have it anywas. So the order of execution is updated below.

hex6x spiboot.rmd

%IBL_UTIL%\bconvert\bconvert64x.exe -<le if .out is a little endian or .be for big endian code> spiboot.btbl spiboot.btbl.be
%IBL_UTIL%\btoccs\b2i2c spiboot.btbl.be spiboot.btbl.i2c
%IBL_UTIL%\btoccs\b2ccs spiboot.btbl.i2c spiboot.i2c.ccs
%IBL_UTIL%\romparse\romparse nysh.spi.map
cp i2crom.ccs spirom_le.dat
byteswapccs i2crom.ccs spirom_le_swap.dat
%IBL_UTIL%\btoccs\ccs2bin   i2crom.ccs     spirom_le.bin
%IBL_UTIL%\btoccs\ccs2bin -swap i2crom.ccs spirom_le.swap.bin

Then you can use the .dat/.bin or _swap.dat/_swap.bin file based on your writer.

Thanks,

Arun.

Arun,

thanks for all this precious information. As you saw in another post http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/240125/841887.aspx#841887, perhpas my problem is not software. The HW engineer seems to believe that the RBL is not accessing our device. Even though the bootstrap setup requests CS1 to be active (low), we do not see any activity on the C6670 (no chip select, no clock) when CS1 is selected.

Remember that on the EVM, you never boot from the RBL, you always have the IBL reconfiguring the SPI interface. This is not our case.

Let me get back to you soon on the SW issue.

Aymeric

Aymeric,

The problem that you are facing now of not able to read more than 0x80 bytes is that the first 0x80 bytes has the boot parameter table configuration. Thius configuration is obtained from the nysh.spi.map file. This one again configures all the parameters for the SPI and this one has npins set to 4 which you need to change to 5 and csel set to 0 whihc you need to change to 1. Try with that and let me know.

Thanks,

Arun.

Thanks Arun,

Considering that I resolved my "HW" issues using the 5 pin mode,, updating the mapping table fed to romparse is the first thing I tried:

..\utilities\romparse -fill 0xff -rom_base 0 ..\utilities\spi.map

with this  section:

section {
  param_index    = 0
  boot_mode      = 50
 sw_pll_prediv = 5
 sw_pll_mult = 32
 sw_pll_postdiv = 2
 sw_pll_flags = 1

 options = 1
 core_freq_mhz = 1000
 next_dev_addr_ext = 0x0
 c2t_delay = 0
 bus_freq_mhz = 0
 bus_freq_khz = 500
 addr_width = 24
 n_pins = 4
 mode = 0
 csel = 1
 exe_file = "boot_code.btbl.be.i2c.ccs"
}

However it still does not configure the second part correctly. I am working on that and hopefully will have some better feedback soon.

I am sure it is coming from the use of the utilities. I have tried so many combination... I will try soon the latest one you advised.

feedback soon

Aymeric

Aymeric,

You still have n_pins as 4. you need to set it to 5 as I mentioned in my previous post.

Thanks,

Arun.

Arun,

I am sorry, this was the wrong copy/paste (I am using 2 PC's), this is the file I was using before you told us about the 5 pin mode.

In the file I am currently using this is our set up.

 addr_width = 24
 n_pins = 5
 mode = 1
 csel = 1

But thanks for the feedback, I know (now) that I made the correct change.

Aymeric

Arun, (Jason),

Let me start by thanking you for your time. Arun, you have move us so much forward in the understanding. The good news are that we believe the boot parameter table seems to be built correctly. The bad news is that after the boot parameters are read, the RBL, jumps the read_addr_msw-read_addr_msw, loads code that is in the flash.

According to what you said, it should:

a) read the _c_int00 and set the magic address (32 bit header record indicating where the loader should branch after it has completed copying the data)

b) load ".text"and ".cinit" and store them in the correct location dictated by the linker (each section  holds a 32 bit section byte count and a 32 bit destination address doe the data to be copied to

c) runs the new code

When running the new code, it completely corrupts the DSP. I cannot run the gel file (default set up command), I cannot access the registers that I wrote to, I cannot reprogram the nor flash...

"Trouble Reading Memory Block at 0x2350808 on Page 0 of Length 0x4: Error 0x00000002/-1202 Error during: Memory,   CPU pipeline is stalled and the CPU is 'not ready'. This means that the CPU has performed an access which has not completed, and the CPU is waiting......"

"Error: Error 0x20000024/-1202 Severe Error during: Register, Execution,   CPU pipeline is stalled and the CPU is 'not ready'. This means that the CPU has performed an access which has not completed, and the CPU is waiting. The target may need to be reset"

At this stage, I need to reprogram the boot mode to anything else than spi (CPLD on our board) then I can access the dsp and do whatever I want.

I followed your advise, I created a very simple project and run the tools, I am attaching this to the post:0028.simple_test.zip

A few more questions:

1) is read_addr_msw and read_addr_lsw from the boot parameter table indicating where the RBL should find the boot table?

2) In the file I sent, this value is 0x400, but when I look at 0x400, I see a value (0x00800CFB) that is not _c_int00. _c_int00 is located four bytes further. This 0x00800CFB was inserted by b2i2c tool at the beginning of the boot table. What is this value? Is that ok for the RBL to jump to this address?

3) Is _c_int00. copied to the magic address location at this stage

Again, thanks for your help, I am still working on this issue and hope you will be able to help again.

Aymeric

PS: Arun, let me help you in turn. The problem with 0x51 that is added to read_addr_msw is not coming randomly. And let me explain:

if you call romparse -rom_base 0 you will force a global variable called i2cRomBase to be forced to whatever value you set in the command (0 in this example). If you do not use the -rom_base option in the command, then when romparse.exe was built, it forced the same variable to be defaulted to the I2C bus address (see Makefile)=> 0x51.

This global variable is used when creating the output file: void createOutput (void)

Arun,

Sorry for sending more but I am working full time on this issues. I have the answer for question2.

b2i2c reformats the file generated by the hex6x utility into section of 128 bytes (size(2bytes) (2 bytes)checksum and 124 bytes of data).

on the other side the RBL,boot_spi_read_block, does the same thing....

I will wait for the other answers while I try to figure out why our code does not boot.

Aymeric

HI Aymeric,

Thanks for the help with the romparse. Let me take a look and update as you suggested.

Here are the answers

1. Yes you are correct.

3. No, it is the last thing that is done by the RBL before it takes the core out of IDLE.

Thanks,

Arun.

Arun,

We are completely stuck and do not have any more idea how to progress. Here is what we see with a scope from start:

read at address 0 => reads 0x50

then reads 80 bytes (boot parameter table) starting at address 4

there is a little delay (assume to reconfigure the spi interface from the boot parameter)

then 4 bytes are read from address 0x400 (set in boot parameter), these 4 bytes are the length and checksum of the next block

then 124 bytes are read from address 0x404 (after the header) => we analysed the first few words read and they seem to be ok.

then it stops....

The RBL is provided in a source code format at this address :

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

But there are no linker information or any file to rebuild the rbl and try it out.... How do I access the section:

#pragma DATA_SECTION (bootLog, ".bootLog")
bootLog_t bootLog;

we want to see what was logged by the RBL.

Thanks

Aymeric

Aymeric,

Can you send you code off line. I can take a look.

Thanks,

Arun.

All was in the zip file 4 post ago but I am attaching it again:6888.boot_code.zip

Code is not going to help you much, it is a write in four addresses as you advised.

The file that we use for the nor_writer (modified to be working with our board on CS1) is spirom_le.swap.bin.

Aymeric

Hi Aymeric

    First of all, thanks for all the efforts that you made and your shareing.I don't know how to express my gratitude. Thank you very much!! I feel like more clearly after reading your posts. 

    We met the same problem as yours. We use TMDC6670 DSP. And we want to boot from SPI directly (no IBL, not EVMs). We have the same spi norflash as the EVM through CS0. Did you finish booting from spi directly on your project?

    I want to ask couple questions and I hope you can help because it's urgent.

   1)Is the "6888.boot_code.zip" that you attach correct?After the steps that the .bat file mentioned, do I have the file to burn into norflash?About the "spi.map", is it fit for us ater we modified the "n_pins" and the "csel" parts?Are there any parts we need to modified as well? Or could you attach your successful reference?

    2)After b2ccs, our .i2c.ccs file is 632KB large. When we use romparse, an error appeared, seems romparse has a limited size of the .i2c.ccs file. Have you tried larger .i2c.ccs file than your attached "6888.boot_code.zip" reference?

    3)Did you use boot configuration table?If so, how to insert the boot configuration table to the boot table?

Best reguards!

Karlphy

Karlphy,

1) Yes, the run_script.bat is the batch file we are using for our IBL. This script will generate spirom_le.swap.bin that you will need to burn on your flash. Of course since you have a different flash that the one on the EVM, you will need to update TI provided not_flash (or more accurately, the platform library that is used by the flasher) to properly burn your flash with the generated image.

the spi.map from the zip file is correct. Our final version is slightly different where we are using the following parameters instead of what you have:

a) the prediv and multiplier that match our HW had to be updated

 sw_pll_prediv = 29
 sw_pll_mult = 472

Note that in romparse (can find the version of the tool) that was provided in mcsdk_2_01_00_03, there is a big bug line 509.

the original code says:

        case SWPLL_PREDIV:    current_table.common.swPllCfg_lsw &= 0x00ff;
                              current_table.common.swPllCfg_lsw |= ((value & 0xff) << 16);
when it should have been

        case SWPLL_PREDIV:    current_table.common.swPllCfg_lsw &= 0x00ff;
                              current_table.common.swPllCfg_lsw |= ((value & 0xff) << 8);

b) we wanted the SPI to boot much faster so we updated to SPI frequency to

 bus_freq_mhz = 25
 bus_freq_khz = 0

By using this frequency, the first "boot_params" are pulled slowly but after reconfiguration, it is a much faster transfer.

2) Of course we have tried with a bigger file. 6688.zip was just a dummy example to have help. Our final .i2c.ccs is 100kB and I did not experience any problem. I read the code of the romparse, I do not think this has a limitation on size. I believe you should look somewhere else for this problem that in romparse. Ask on the forum, the guy that helps (Arun usually) is very knowledgeable.

3) Now we use a simple boot. Our goal was just to do some basic init of the PCIe bus with samller bar size and some things on the side.

Good luck resolving your problems, I hope I could help a bit

Hi, Aymeric:

Thanks for the help! You helped a lot and we appreciate for that, thank you. Now after two days tried, we still have couple question, we hope you can help patiently. 

1)

"a) the prediv and multiplier that match our HW had to be updated

 sw_pll_prediv = 29
 sw_pll_mult = 472"

Why is the option of PLL in boot parameter table set like this? The BoodLoader User Guild mentioned:"for no boot, i2c boot and spi boot, the PLL stays in bypass mode."

2)B2i2c has a limit file size of 0x20000. We change the limited size and rebuild the utility successfully, using visual studio2008.But we failed at rebuilding the romparse utility. Since you have fixed the big bug in line 509, can you tell me what tools did you use to rebuild the utility? We must fixed the big bug line and change the limited file size. 

Best reguards!

Karlphy

Hey Karlphy,

Glad to hear that you are making some progress.

1) I will not guarantee that my answer is the exact answer but as far as I understand it. The boot process is a 2 stage process. The first process where the RBL will take the "bootstrap" settings and boot from these settings.Since PLL stays in bypass mode, the pll setting from the boot strap are not used. However, during this first stage, the "boot parameters" are extracted from the the binary image in your flash. These boot parameters are then used to reconfigure the peripherals. In the case of my map file, I set the pll to what is in this table (2.4.3 PLL Settings)

in_clk 122.88 => (divider) 28 (multiplier)471  gives me ~ 1GHz frequency

2) I will keep in mind that there is a size limitation  for B2i2c, if I get to such a big image, I may find the same problem.

To answer your question, the romparse binary is rebuilt as part of building TI IBL (see: TI_MCSDK\mcsdk_2_01_00_03\tools\boot_loader\ibl\doc\evmc6670-instructions.txt ) it is explain quite well how to do this.

Hope it helps

Aymeric

Hi, Aymeric

How are you ! Long time no see~~Our digital board has just arrived and finished hardware debugging. And I'm trying to test the bootloader.It is ashamed that I met some incredible questions and some misunderstandings in the boot parameter table.Maybe you could help, can you help me, please?

Environment description:Evm C6670, no IBL not EVM, boot from spi directly, the norflash is connected to the DSP via CS0. The norflash can read and write correctly.

1)Here is my understanding of boot parameter table(spi.map), maybe you can find it similar to yours, haha.Can you check it for me base on your own standing?

section {
 param_index    = 0
 boot_mode      = 50
 sw_pll_prediv = 1  (Our input clock is 100MHz,. Are these sw_pll settings correct for my digitalboard?)
 sw_pll_mult = 20 (100MHz / 1 * 20 / 2 = 1GHz?)
 sw_pll_postdiv = 2
 sw_pll_flags = 1

 options = 1 (What does it mean? Why it is 1 but not 0? According to the users guild, 1 means boot from boot table, and 0 means boot from boot parameter table. Doesn't it ought to boot from boot parameter table, I'm so confuse about this.)
 core_freq_mhz = 1000
 next_dev_addr_ext = 0x0 (What does this addr mean? Why it is 0x0 in your project?)
 c2t_delay = 0
 bus_freq_mhz = 20
 bus_freq_khz = 0
 addr_width = 24
 n_pins = 4
 mode = 1
 csel = 0
 exe_file = "boot_code.btbl.i2c.ccs"
}

2)When the option (in the parameter table) is set to 1, I use oscilloscope to test the norflash pins, I found that the DSP send the read 0x510400 command continuously(like endless loop) .The MISO pin send the four bytes in 0x510400 continuously(like endless loop) , it is all 0Xff and the value is correct.

When the option is set to 1, it shows the same performence but the read address is 0x000000, and the value of 0x000000 is 00000500(correct).

This is what I can't quite understand at all.Why doesn't is read the next addr after finish reading the current address value.I have no idea about that, maybe I have do someting wrong and I don't take notice of it.

Can you tell me something about these questions in your opinion or anything you can suggest me to do?I know it is greedy to ask for your help and spend your time, but I hope you could help me since your are pioneer and maybe you met these questions before. Thank you.

Best Regards,

Karlphy

Hi, Aymeric

I have made some progress these days. According to your attached reference, we boot the dummy project successfully! And I remember that your project do not need to use the DDR to store part of the codes. Now I have two issues, I hope you can answer one question of two for me, our development environment is almost the same, I can't find anyone more suitable. I have post lots of posts on the community but no one answers.  

Now we met two big issues, I hope you can answer the first one for me, please, thank you.

1)Multicore boot. Did you use mergebtbl ultinity or MAD ultinity to boot more than one cores?Can you show me how to boot multicore? An example or some documents or some advises is helpful, please, thank you.

2)Some of our codes need to be stored in DDR, so we need to use the boot configuration table. The documents and user's guilds only describe what is it looks like or what it does. I have no idea on appending the boot configuration table to boot table using romparse.(The bootloader user's guide mentioned in 2.5.5"Romparse is used to append the boot parameter to boot table or a aboot configuration table.")

I hope you can give me some help. Thanks a lot!

Karlphy

Hey Karlphy,

I did not see the previous post, sorry, I am only seeing it now but I will try to provide you with answers. I am far from being an expert in bootloader, I just struggled to get our working and gain a lot of understanding in the process.

1) regarding the muticore boot, I am not sure how it works since we are not using muticore What I know is that in some of TI manual, they say that core 0 is in charge of booting the other cores.

After POR, core 1, 2, 3 are waiting for something to happen to start booting (inter process interrupt). I think you should consider downloading the RBL code from TI and look at the code, it will help you in the understanding.

I have never used the MAD tools or any of the multicore tools.

2) Again, I am not an expert, but I am correct, after POR, the external ram controller is not initialized. Until some of your code runs to initialize it, I do not believe you can access anything in the RAM. Again, I am not an expert but if I had to boot several cores after POR and had to use external ram, this is what I would do:

a) create a header binary format for each core and make a binary for core0 that would be small enough to fit in L2

b) put the core0 binary at sector0 and all the other binary at other sectors of your flash

c) have core 0 boot, init the external ram (see platform_init function), and only then have core 0 loading the other binaries from flash in memory

d) finally, have core 0 updating the boot address for each core and get them to start from each _c_int00 address

I am sure TI has a better way to do this but I believe this would be working. I would advise to look at what TI is doing in c:\TI_MCSDK\mcsdk_2_01_00_03\tools\boot_loader\examples\pcie\ that might help you.

Regarding your previous post, your PLL settings seem ok according to 2.4.3 PLL settings and section 7.5

The ext dev address is not used I beleive but again you should look at the RBL source code to see what they are doing with the parameters on boot. According to tiboot.h, the option field is used as follow:

    /*
     * SPI Specific Options
     * Bit 01-00: BT:                                      
     *            00 - Boot Parameter Mode                            
     *            01 - Boot Table Mode                     
     *            10 - Boot Config mode
     *            11 - Reserved, but if seen will act as boot parameter table
     * Other bits:  Reserved
     */
     #define BOOT_PARAMS_SPI_OPTIONS_BP             0x0000
     #define BOOT_PARAMS_SPI_OPTIONS_BT             0x0001
     #define BOOT_PARAMS_SPI_OPTIONS_BC             0x0002

And we are using the boot table.  The reason why you read 0x0500 is because the RBL needs to read the parameters in BE (I think) and in fact what is read is really 0x50 which is the size of the parameters that the RBL will read to reconfigure the SPI interface.

Trust me, read the RBL code, it is very instructive...

Anyway, I hope it helps and I recommend to try to have Arun help you. He is the man that will help you out.

Aymeric

Hi Aymeric/ Arun,

Just going through your discussion and found my problem is also matching with this. Anyways, i was also searching finally which file has to be dumped in nor flash??  Arun is saying based on nor writer we have to decide. 

could you pls tell me from  which part of the code (norwriter.c) this info can be found??

rgds,

Gourav