RBL memory boot on EVMK2H

Brian,

Thank you for the post. We will get back to you as soon as possible.

Brian,

Please refer to my response and example on the e2e thread here:

e2e.ti.com/.../1945745

THe code in testsmall.c has all the required IPCGR setting to wake up slave cores. Please review the code and let us know if you have any questions regarding the same.

Regards,
Rahul

Thank you!
Does RBL DSP Nor flash boot or RBL DSP Nand flash boot on EVMK2H can support multi-core boot or multi Stage boot ?

Yes, all boot modes can support multi-core boot and multi-stage boot. The example that I have provided boots on core0 and then wakes up all slave cores. It is a single stage boot examples but you can reenter boot using _romtBootReentry address on DSP side which is 0x20b00008.

For ARM boot re-entry address, refer:
processors.wiki.ti.com/.../KeystoneII_Boot_Examples

Regards,
Rahul

Hi Rahul,

The testsmall.c is for ARM core & DSP core .

I use IPCGR only for DSP core.

What things in the example code should I notice ?

Hi Rahul,

To boot this example, where should Boot modes switch be switched to ?

Any of spirom.swap.dat & spirom.bin can be loaded by RBL in EVMK2H?

After it has a successful boot, what happens?

How can I confirm the example boots successfully?

Thank you.

The K2H EVM hardware has been configured to support only ARM as the boot master. In order to set DSP as the boot master, you will need to use the BMC UART console and configure the DSP SPI boot mode as follows:

>bootmode #8 0 <BootMode >
>bootmode #8
>reboot

Compute Bootmode using description of Bootmode[15:0] in DEVSTAT register. After the device successfully boots, you will see the ARM and the DSP core execute code in MSMC /DDR (look at the program counter (PC))

Regards,
Rahul

 Hi Rahul and experts,

There are some questions about 4846.DSP_SPI_boot_example.zip below:

Q1:

hawking_arm.rmd

ROMS

{

       ROM1 : origin = 0x0c010800  length = 0x0800 romwidth = 32 memwidth = 32

                 files = {  testsmall_arm.b }

}

     1. Why the origin value is 0x0c010800 in “ROM1 : origin” ?

      2.  Is the origin value from testsmall_arm.map?

 

Q2:

1. To boot this example, where should Boot modes switch be switched to ?
2. Any of spirom.swap.dat & spirom.bin can be loaded by RBL in EVMK2H?

 

Q3:

1. Does the ARM core support .btbl format?
2. Could you tell me a generation process and used tools of the testsmall.btbl.ccs (such as .out—[hex6x]--> btbl)  ?

 

Q4:

1. What meanings are these terms in spirom.map?
2. Could you offer me any reference document?

 

Q5:

Can the romtMonitorFunction function use DSP core to wake up the other cores?

Best Regards, 
Brian

 

Brian Li said:

Q1:

hawking_arm.rmd

ROMS

{

       ROM1 : origin = 0x0c010800  length = 0x0800 romwidth = 32 memwidth = 32

                 files = {  testsmall_arm.b }

}

     1. Why the origin value is 0x0c010800 in “ROM1 : origin” ?

      2.  Is the origin value from testsmall_arm.map?

Yes, the hexarm utility in the TI ARM compiler is used to create a contiguous binary image and the origin specifies the first memory location from which the utility should scan for memory sections. you can pick the origin from the map file by looking at the first memory section that has been used in the ARM binary. 

In the map file even if you have IPCGR and IPCAR sections in the map file before the ARM_ENTRY, those sections are unused and hence can be ignore. for more details on creating  the .rmd file, refer to the TI ARM compiler documentation available under ccsv6\tools\compiler\ti-cgt-arm_xx_xx\docs

Brian Li said:

Q2:

1. To boot this example, where should Boot modes switch be switched to ?
2. Any of spirom.swap.dat & spirom.bin can be loaded by RBL in EVMK2H?

 

the boot mode on the EVM is typically set using the boot switches but the boot switches currently support only 16 different ARM boot modes. The rest of the boot modes can be configured through the BMC UART console. I have provided instructions regarding this in your other e2e post from this morning. You will need to use the NOR writer provided in the Processor SDK to flash the image as described here:

Brian Li said:

Q3:

1. Does the ARM core support .btbl format?
2. Could you tell me a generation process and used tools of the testsmall.btbl.ccs (such as .out—[hex6x]--> btbl)  ?

No, ARM supports general purpose header format and not boot table format.  The process for generating the DSP binary can be seen from the makefile in that example.

hex6x -a -boot -bootorg 0x400 -romwidth 32 -memwidth 32 $< -o btbl.b
b2ccs btbl.b testsmall.btbl.ccs

ccsi2cblock 0x80 -infile testsmall.btbl.ccs -outfile testsmall.btbl.i2c.ccs

romparse -nTables 1 -noPci spirom.map
cp -f i2crom.ccs spirom.dat
byteswapccs spirom.dat spirom.swap.dat
ccs2bin spirom.swap.dat spirom.bin

Brian Li said:

Q4:

1. What meanings are these terms in spirom.map?
2. Could you offer me any reference document?

spirom.map contains the boot parameter table that gets appended to the boot table. the ROM code reads the boot parameter table to configure the clocks and to setup the device.

Unfortunately, most users on the K2H devices are using ARM boot as the master so we have documentation and examples mostly supporting that usecase. For DSP boot, we only have DSP Bootloader USer guide that only explains the functioning of the bootloader and the example that I provided provides the necessary utilities.

Brian Li said:

Q5:

Can the romtMonitorFunction function use DSP core to wake up the other cores?

romtMonitorFunction is only required for ARM to wakeup other cores, the DSP can access BOOTCFG registers without requiring boot monitor function. Refer to testsmall.c in the example

regards,

Rahul

Hi Rahul,

After 4846.DSP_SPI_boot_example has booted successfully , what is its result?
How can I confirm the example boots successfully?
For example, any of global variables changing it value following the code let me check whether is the boot successful?
any other way?

Thank you!