Debugging boot code ?

Are you using the same NAND device as in the EVM. The source code for the ibl is in the MCSDK folder that is created during the install. Having said that, one thing you can check is if possible connect the Device through CCS and see where the PC is halted. Also if you know the memory map of the image you are loading from NAND, check the address locations to see if the transfer from NAND happened successfully.

 

Thanks,

Arun.

Hello Koray,

 Since you mentioned that your custom board has a different FPGA image, you should have a look at the the functions in the file src/device/c66x/c66xinit.c. This file has some implementation which is board specific (FPGA specific also).

As a first step I would suggest that you compile out board specific parts of this code by undefining the following MACRO's in the file src/device/c66x/target.h

#define IBL_ENTER_ROM              1

#define IBL_ENABLE_PCIE_WORKAROUND 1

Regards

Sandeep

I am examining ibl source and there are some points that I didn't understand:

• There are two main() functions in ibl source code. One of them is for initialization(iblinit) and the other is the main ibl. Does it mean that these applications reside in seperate boot tables?
• In the code, it says ibl structure is in a fixed area in the memory. Where is it ? I didn't see any information about this issue in the documents. I understand that at power-on, this table is updated from EEPROM configuration tables which we have loaded using i2cConfig.gel. Am I right ?
• There is a thing called 'Boot table processor'. What is it ? And how is it used ?
• Lastly, is it possible to compile and run ibl source code like a CCS project ?

Regards,

koray.

Hi Koray,

 Please find the response inline.

• There are two main() functions in ibl source code. One of them is for initialization(iblinit) and the other is the main ibl. Does it mean that these applications reside in seperate boot tables?

         > IBL is split into 2 stages. The main() is iblinit.c is loaded by the ROM boot loader. This configures the device PLL's and loads the second stage IBL. The second stage IBL is stored in boot table format in the EEPROM. The address offset for the 2nd stage IBL is read from the MAP table which is stored in EEPROM at offset  IBL_CFG_I2C_MAP_TABLE_DATA_ADDR.

• In the code, it says ibl structure is in a fixed area in the memory. Where is it ? I didn't see any information about this issue in the documents. I understand that at power-on, this table is updated from EEPROM configuration tables which we have loaded using i2cConfig.gel. Am I right ?

        > The IBL configuration table is stored at a fixed offset in EEPROM configured by IBL_I2C_CFG_TABLE_DATA_ADDR. This table is read from EEPROM by the second stage IBL.

• There is a thing called 'Boot table processor'. What is it ? And how is it used ?

        > This is used to load the second stage IBL from EEPROM.

• Lastly, is it possible to compile and run ibl source code like a CCS project ?

         > It is not possible to make it a CCS project. But you should be able to do source level debugging for IBL using CCS. To compile IBL with debug symbols you have to give the option DEBUG=yes while invoking the make command. While building with DEBUG option you may get linker failures due to memory region sizes defined in src\make\ibl_c66x\ibl_common.inc. Please increase/adjust the size depending on the link error. You can the load symbols from ibl_c66x_init.out (first stage IBL) & ibl_c66x.out (second stage IBL) for source debugging.

 

Regards

Sandeep

Hello again,

About debugging issue, I examined the make file and I saw that it uses Texas tool chain compiler. The point I did not understand is even it uses Texas compiler why  can't I compile and debug it using CCS ? And by 'source level debugging' do you mean tracing the  code but not having its built output run or debug on the EVM board ?

Also you are mentioning on 2 different out files(ibl_c66x_init.out, ibl_c66x.out) but when I built ibl by means of makefile, there is only one out file at the output(i2cparam_0x51_c6678_le_0x500.out). Also, in the build_instructions.txt file, it is written that only one out file should be generated at the output. I am confused on this issue ?

Regards,

koray.

 

Hello Koray,

 The "make" process does more than just creating ELF executables. If you observe, the output file which you flash on the eeprom is not an ELF file, but its an EEPROM image file (in boot table format) which is loadable by the ROM bootloader.  The  2 out files(ibl_c66x_init.out, ibl_c66x.out) along with some other information are converted into " boot table" format and laid out as a EEPROM image.

For debugging purpose you can load these intermediate ".out" files using CCS and step through the code. 

The out file "i2cparam_0x51_c6678_le_0x500.out" is not IBL. It is a utility to program the IBL configuration data on the EEPROM.  The instructions for programming IBL on the EVM are given in the "doc" directory of IBL source distribution. 

 Regards

Sandeep

Hello Sandeep,

We already loaded ibl_c66x_init.out file using CCS and tried to step through the source code. However after a couple of lines, the debugger couldn't find the necessary debug symbol and stopped the debug process. So we couldn't go any further.

Any idea ?

regards,

koray.

Hi Koray,

 Did you enable the debug option while doing the "make". Other than that I'm not sure what could be the issue. When you say that "it couldn't find the debug symbol", do you mean it was not able to locate the source file?

Regards

Sandeep

Yes I enabled the debug option, and then I even had to change the mapping of the sections in ibl_common.inc because of the region size error I did get.

And you are right, when I say that "it couldn't find the debug symbol", I am meaning it was not able to locate the source file.

koray.

 

Hi Koray,

Are you not able to proceed with source debugging by manually locating the source file for CCS. This can be done by clicking the "locate file" button in the CCS source browser window.

Regards

Sandeep

Hi Sandeep,

We managed to do source level debugging by locating missing source files manually within the CCS environment. But now we are confused at some point in the main function of 1st stage ibl(ibl_c66x_init.out).

It seems to jump into bootrom again after retrieving the boot mode is i2c and i2c initialization is completed. It enters into a function called  iblEnterRom(). Within this function, it seems to apply some SPI initialization procedures and it retrieves the bootmode one more time. After that point, the flow of the control jumps into the bootrom via a function pointer which points at the entry point of the bootrom.Why does it turn the control back to the bootrom again ? And if so, what does the code within the bootrom do after this point? And how is the 2nd stage bootloader activated ?  Also, why is SPI initialization needed ?

One more point, after iblEnterRom() is called, there are still some lines of code within the main function of 1st stage ibl. After jumping into the bootrom again, we do not expect these lines to be executed. How are there lines executed ?

regards,

koray.

Hi Koray,

 This is done to provide a workaround for the PLL lockup issue (refer to C6678 Silicon errata document, Rev. C, advisory 8). On C6678 lite EVMs, the DSP will always boot IBL from I2C EEPROM bus address 0x51 which provides the PLL reset workaround. The sequence is as follows:

1. FPGA samples the bootmode pins

2. FPGA forces the DSP to boot via I2C bus address 0x51

3. PLL is initialized correctly by the IBL on the I2C.

4. IBL reads the sampled bootmode from an FPGA register and writes this value into the DEVSTAT register

5. IBL writes the Boot ROM entry address into the DSP Program Counter

6. DSP executes the desired internal ROM boot mode as normal

So the second stage IBL will be executed only if the ROM boot mode is for I2C bus address 0x51. i.e. iblEnterRom() will return if the ROM boot mode is for I2C Bus address 0x51.

Regards

Sandeep

 

Hello Sandeep,

thanks for your fast reply. It helped a lot to understand the bootstrap flow.

Now, we are trying to execute 1st stage bootloader on our board in the debug mode. When we select the i2c 0x50 eprom boot mode option,
everything seems to work fine and the application is loaded successfully (1st stage ibl is loaded on i2c 0x51 eprom address then flow jumps back into the BOOTROM).

However, when we select the the nand image0 boot mode option, the application cannot be loaded. There is a function within the 1st stage ibl
called "iblBootBtbl". This function seems to load data from eeprom over i2c by means of a state-machine approach. It loops through the block of the eeprom
until it retrieves the necessary data and the control is given back to the BOOTROM. However, on our board, this loop never terminates and the traffic over
i2c bus never stops.

What kind of data is trying to be loaded from eeprom? Do we need anything to do with the boot tables so that it can completes this state machine?

Regards,
Koray

 

Hi Koray,

 The IBL configuration data, and the second stage IBL code are read from I2C eeprom by the first stage IBL. So to move forward with the debugging you need to program the IBL eeprom image on the I2C eeprom of your board.

Regards

Sandeep

Hi Koray,

 Forgot to answer your original question: iblBootBtbl() is being called to load the second stage IBL.

Regards

Sandeep

Hi Sandeep,

I forgot to say that at the beginning of our debug process we flashed the 6678 EVM factory images to our board for keeping the same configuration with the 6678L EVM. With the factory image script(program_evm.js), we programmed 0x50 eprom, 0x51 eprom and NAND flash successfully on our board. So I think that we do not need to do any extra programming for 0x51 eprom. Am I right ? 

Hi Sandeep,

We have already burned the factory images which come along with the EVM board on our own board. Therefore, 1st and 2nd stage IBLs
exist on EEPROM i2c bus address 0x51 during the debug session. We have another observation which goes as follows:

- We have monitored the i2c bus traffic both on EVM and our own board.

- The flow is the same until the EEPROM address of 0x8380. Our own board retrieves the same data again at this address. However,
it keeps on polling this address and loops infinitely.

What might be missing on our own board's EEPROM i2c bus address of 0x50 and 0x51, although we had burned the factory images?

Regards,

Koray

Hi Koray,

 I'm not sure about what could be the issue that the boot table read is getting stuck on your board at offset 0x8380.

Is the EEPROM size on your board same as the EVM i.e the bank at I2C address 0x51 is 64 KB?

Can you read back 64KB of data from I2C bus address 0x51 and compare it with the factory image?

Regards

Sandeep