bootloader ROM re-entry

Hi Jeff,

I am a little confused regarding your boot scenario. IBL is a secondary bootloader code that resides in the I2C EEPROM that will execute after you have exitted the ROM bootloader. Can you please explain what you mean by reenter RBLand perform IBL boot. Are you saying you want to initilally boot the EVM to run the image1 (POST) example and after the tests have run re-enter IBL to execute your application.

We don`t have procedure documented to reboot from I2C as this is a custom boot scenario and not a typical boot flow but if the intent is simply to re-enter RBL then you caneither  use the iblEnterRom function that is defined the IBL after you POST example has run from the I2C or chnage the Program counter to the base of L2 ROM. which is the ROM entry address. 

I would also recommend that you look at the iblinit.c file in the IBL source code to see how it enters the ROM (if required) and also if you don`t want to run the RBL and just want to directly go to the start of the IBL you can do the following.

iblStatus.iblMagic     = ibl_MAGIC_VALUE;
iblStatus.activeDevice = ibl_ACTIVE_DEVICE_I2C;

bFxnTbl = iblInitI2c ();

iblBootBtbl (bFxnTbl, &entry);

exit = (void (*)())entry;
(*exit)();

Please let us know if you run into any issues.

Regards,

Rahul

Jeff,

We have example like that in IBL already, you can refer to:

C:\ti\mcsdk_2_01_02_06\tools\boot_loader\ibl\src\device\c66x\c66xinit.c, function iblEnterRom(),

In line 359 to 365: at the end of your POST program, you need to program DEVSTAT register to force it to use IBL boot when reboot happens. Program DEVSTAT register with a correct a value (look into data sheet).

Then line  388 & 389, the code shows how you can go back to RBL again:

        exit = (void (*)())BOOT_ROM_ENTER_ADDRESS;
        (*exit)();

The idea is  you need to extract the portion for doing "reprogram DEVSTAT and then jump back to RBL again".

However, I assume your current level boot mode for booting POST is not through i2c, otherwise, how would RBL distinguishes the POST boot and IBL boot?

best regards,

David Zhou

David-

> The idea is  you need to extract the portion for doing
>"reprogram DEVSTAT and then jump back to RBL again".

My understanding is that DEVSTAT would be overwritten by a CPU "hard reset" (which we know how to do by programming RSTCTRL register) so we can't do that.

> However, I assume your current level boot mode for booting
> POST is not through i2c, otherwise, how would RBL
>distinguishes the POST boot and IBL boot?

Yes we are booting through I2C EEPROM, so we don't want to restart the boot process from zero (i.e. hard reset, and indeed we don't need to as we've initialized everything we're going to need in our POST program), we simply want to re-enter the bootloader at a point where it "thinks" it's doing IBL boot.

Will your example above (modifying DEVSTAT) work in this case?  Thanks.

-Jeff

Jeff,

DEVSTAT can be changed even after power on reset. You need to program KICK0 & KICK1 register first. Please search for KICK0 in datasheet. As you can see, IBL is already changing DEVSTAT in the code, you can do the same thing.

So the first time it is I2C boot, is the 2nd time also doing the i2c boot or another boot? If it is another boot mode, it will work with ease with a different DEVSTAT value. If it is still I2C boot, it still can work but you have be careful in order to distinguish with the first i2c boot.  Otherwise, it is a forever loop. You can optionally use the boot parameter index. Do you have two EEPROM on the board?

I need to get more information.

best regards,

David Zhou

David-

Thanks for your replies.  We will experiment with modifying DEVSTAT and re-entering the bootloader at it's base address (0x20b00000).

Our desired IBL boot mode is Ethernet TFTP.  Our thinking is that to cause IBL (and *not* some other RBL boot mode, like Ethernet instead of I2C), we can't simply jump to 0x20b00000.  We need to jump to a specific place inside the bootloader -- can you confirm this and provide the correct addr?

Why do we need to re-program KICK0 and KICK1 registers?  The chip is already up and running...

-Jeff

The kicker mechanism is unlocked by the ROM code but any spuious write to KICK registers will block any writes to Bootcfg registers. So it is a good practive to unlock the KICK registers before writing to any MMR Rgisters like DEVSTAT register that are defined in the BootCfg space and then to lock them to prevent spurious writes to those registers.

Regards,

Rahul

Rahul-

Ok thanks, we can put that in.  But this does not address the main issue.  Here's what we're doing so far:

1) Boot from I2C address 0x50 our modified POST program, which includes command-line prompt.

2) From our program command prompt, we enter a command that does:

  -modifies DEVSTAT for I2C boot, address 0x51
  -sets boot configuration table index to 4 (TFTP)
  -re-enters bootloader at address 0x20b00000

We are not seeing TFTP requests yet on Wireshark.  What are we missing in the above procedure?

-Jeff

PS. As a sanity note, using the above procedure, if we change the boot mode to RBL Ethernet (not I2C), we can see BOOTP requests on Wireshark.

Hi Jeff,

Before you start testing the TFTP boot after re-entering ROM, have you tested the MCSDK provided I2C TFTP boot example on your platform. If yes, then please provide us the following information.

After the post example has run and you re-enter the ROM do you see the DSP exit the ROM ? Check the program counter to determine if ROM has executed. If the ROM has executed can you re-confirm that the DEVSTAT value is still at what you programmed after the POST program executed.

I believe the ROM maintains the I2C boot parameter table at 0x00873680. Can you read the I2C paramter table field values using the I2C parameter table defined in tiboot_c66x.h (In IBL source in MCSDK)and let us know if the value in the parameter table match when you run the example directly as compared to the case where you re-enter the RBL after executing Post example.

Regards,

Rahul

Rahul-

It's very difficult to change I2C addr bootstrap pins on our board, so for the time being we're stuck with 0x50 boot, then re-boot from 0x51 using DEVSTAT and ROM re-entry, as discussed above.

We can set a breakpoint at 0x20b00000, and follow bootloader code line-by-line, is there source and symbol file info we can use to see if we get to the point of jumping to start of IBL?  Our board is mostly based on the EVM 6678 so we should see UART output once IBL runs, but we don't get that far.  (Note -- our UART output works fine as that's what we use in our modified POST program).

One thing we don't have on our board is the EVM's FPGA SPI interface, will that cause an issue?

Thanks.

-Jeff

David-

> So the first time it is I2C boot, is the 2nd time also doing
> the i2c boot or another boot?

Yes another I2C boot, at addr 0x51.  If we write DEVSTAT to 0x100B we can reboot from 0x50 without problem.  If we write DEVSTAT to 0x184B and set a breakpoint as follows:

           exit = (void (*)())BOOT_ROM_ENTER_ADDRESS;
   --> bp  (*exit)();


we see the PC go to 0x20b00000 and we can single-step from there.  Is there a breakpoint we can set to verify that IBL has loaded from 0x51 and is about to execute?  Is there C source and symbol info to allow us to step through IBL?  Is there a .out file?  Thanks.

-Jeff

Rahul-

> Before you start testing the TFTP boot after re-entering ROM,
> have you tested the MCSDK provided I2C TFTP boot example on
> your platform. If yes, then please provide us the following
> information.

Is this a separate CCS project we can run, without using IBL?  If so where is this?

> After the post example has run and you re-enter the ROM do
> you see the DSP exit the ROM ? Check the program counter
> to determine if ROM has executed.

Are you referring to start of IBL code after being loaded by the onchip bootloader?  If so what breakpoint can we use to see if onchip ROM has been exited?  Thanks.

-Jeff

Jeff,

On MCSDK 2.1.2.6, there is no prebuild *.out files. But there is instructions to rebuild it:

C:\ti\mcsdk_2_01_02_06\tools\boot_loader\ibl\doc\build_instructions.txt

Please note the following minor things(unfortunately this was not in above instructions document);

1) the compiler can be downloaded here:

http://software-dl.ti.com/codegen/non-esd/downloads/download.htm

2) when you install compiler, you can install it under: c:\Program Files, not c:\Program Files (x86). it will work will latter as well but you need to modify setupenvMsys.sh properly. I will just do the simple way;

3) If you use Windows, go to  c:\MinGW\msys\1.0\msys.bat to launch the MinGW-MSYS shell

then go to c:\ti\mcsdk_2_01_02_06\tools\boot_loader\ibl\src\make folder,

make sure you type in this:

PATH=/c/MinGW/bin:$PATH

4) then make evm_c6678_i2c ENDIAN=little I2C_BUS_ADDR=0x51

Then the *.out files are in make\ibl_c66x folder, please note they are two out file as IBL itself is also two stage.

I also want to point out if you compare your built i2crom_0x51_c6678_le.bin vs existing one, if they are not binary exact, which means the *.out files are not matching the IBL preprogrammed. In that case, you can still load symbol and give it a try but to be safe, it is a good practice to reprogram IBL to get it matched.

After you load symbol, you can see where PC is and also I'd recommend  you look at iblStatus structure to see if it is doing the TFTP boot you desire. If not, check even if the first step of IBL boot (*init*.out) is working or not.

case ibl_BOOT_MODE_TFTP:
                iblStatus.activeDevice = ibl_ACTIVE_DEVICE_ETH;

Good luck!

best regards,

David Zhou

David-

Thanks we will try this.

But can you *please* answer my questions about where to put breakpoints?  The first thing we need to know is what is the onchip bootloader doing after re-entry.  If it's not even getting IBL loaded and jumping to it, then we need to know.

This can't be that hard -- onchip bootloader code is fixed, right?  So where are the key places to put breakpoints?  This should be documented.

-Jeff

Hi Jeff,

We do provide the source files for the C6678 RBL on the wiki poage :

http://processors.wiki.ti.com/index.php/Keystone_Device_Architecture#Keystone_ROM_Boot_Examples_and_Reference_code

The release however doesn`t provide the ROM out file and the map files so it may not be useful beyond understanding the code flow. I understand that you won`t be able to modify the I2C settings on your board but can you use the EVM to verify that the IBL image you are using for TFTP boot does work on it.

ALso were you able to capture the program counter when you don`t see any TFTP requests  on wireshark? IBL can be built into a .out using makefiles and not CCS project. Prebuilt IBL binaries can be found in the folder

C:\ti\mcsdk_2_01_02_06\tools\boot_loader\ibl\src\make\bin

and you can build the IBL source using the instructions provided here:

http://linux-c6x.org/wiki/index.php/IBL_version_1.0.0.11

Regards,

Rahul

You won`t be able to set a break point without knowing that IBL has loaded from I2C address 0x51. The way to confirm device exitted from RBL is to  connect to the target without a GEL file after you see no TFTP boot requests  and look at the program counter. If the DSP PC is not in the L2ROM space the ROM has exitted. If it has exitted look at the PC and try to assosciate it with the IBL sysmbols to find where it has stopped executing.

Regards,

Rahul

Rahul-

After re-entering the onchip bootloader to start an IBL, we've not yet seen the PC outside of L2ROM space.  Are there other ways to see bootloader progress?  If some IBL code has been loaded to L2 mem, where can we look?  Does the boot parameter table get copied first to L2 mem, and if so which address? Does the bootloader store any type of status or log, for example in MCSRAM?

Also this post

  http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/318830.aspx

mentions bootloader re-entry address of 0x20b00008.  Is that correct or 0x20b00000?

Thanks.

-Jeff