C6678 2 level Srio 4x Boot, using Spi Boot parameter table

Here are my answers

- Is there a software demo or code  for Srio boot using messaging.?!

<AVM> MCSDK has a demo. Please take a look at mcsdk_2_01_02_05\tools\boot_loader\examples\srio

The documentation is not clear enough to me  -

 - what does the end of boot packet mean ? how does it look?

is it just the end of the boot table?

<AVM> Yes

in the message mode boot header what does block size=6 means?

is this header the data at the beginning of each srio message? why 6?

is this header  a 32 bit ? how big is the block size field? 

<AVM> There is a typo here. The block size is size of packet + 4 byte header.

Do i have to add a checksum for each message?

<AVM> It is not required.

- about Spi - do you have an example file of an spi boot parameter table for rebooting srio in 4x lanes?

<AVM> Nope. but please check the e2e, i have posted a few examples that you can used as reference.

- Another option is not to use Spi at all, to boot from Srio and than

through the switch send the command of moving to 4 lanes to all Dsp's,

what do you think about this option in term of feasibility, stability and boot speed.

does it seem to be a better option ?

<AVM> I don't much about the SRIO switch to make this judgement call. I can ask an SRIO expert to respond.

Thanks,

Arun.

Arun,

Thank you for your prompt reply.

about

ArunMani said:

<AVM> MCSDK has a demo. Please take a look at mcsdk_2_01_02_05\tools\boot_loader\examples\srio

As far as i understand This example uses Direct IO,

our need is for an example for booting SRIO in messaging mode

(which is different than DirectIO)

This is why i asked about the checksum, which is described as part of the header for each message.

as described in the boot loader document - sprugyy5b

ArunMani said:

<AVM> There is a typo here. The block size is size of packet + 4 byte header.

Do you mean each Srio message should include a header with the size of current packet(including the 4 bytes of the header it self?)

ArunMani said:

<AVM> Nope. but please check the e2e, i have posted a few examples that you can used as reference.

Can you refer/link to the examples you mean?

About srio, we can init DDR the same way you do in the example in

mcsdk_2_01_02_05\tools\boot_loader\examples\srio

by loading first a ddrInit code, and than SrioInit code, both through Srio

About the option of changing the lanes - I tried to Add it to the example you give to Srio boot.

It says it loaded both ddr init and application code, but doesn't print to the Uart (it does print if i don't change lanes number)

for changing the lanes i tried to add to the srioinit code in the example 

both a code i found here in the forums

and a code for changing the lanes i found in the srio tput benchmarking example

Hello Are and other

Any Feedback?

Hi Nissim,

For messaging mode all you need to do is

1. Convert the image into boot table.

2. Chunk the boot table and generate SRIO packets and send.( you can see how you send messages from the SRIO Multicore example which is in the SRIO LLD in PDK package).

The checksum is always optional. About the header, yes, you need to append the header for each SRIO packet you are sending and the size of the packet is now the data size +4 byte you are appending.

the link below is a SPI boot example. you can use this as reference.

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

This is still only SPI boot, as I mentioned I don't have a SRIO boot through SPI.

Thanks,

Arun.

Nissim,

I would try one thing at a time. First try the SRIO changing lanes and see if that helps. if not, please send me the code, I can take a look.

Thanks,

Arun.

Arun thank you.

It would be very useful if TI could supply an example code for boot

using messaging (or add it to the existing example) .

Hello Arun,

We are struggling for more than a week trying bring up a basic srio messaging boot on C6678

we are working with 2 EVM's connected through Rapidio.

we are trying both based on the direct io example supplied and
on the multicore loopback example
with no success.

2 things that could really help -

a. suppling code bsased on those exmaples

b. if a is hare to supply - supplying a project that can be compiled and simulate the boot rom code on the receiving side so we can simulate receiving the packets.

A quick reply would be very helpful

Thanks,

Ilay

Thanks Arun

A bit more info.

The boot will be done through srio type9 messages.

which is the only way we plan to work right now with RapidIO.

The Direct  IO example from mcsdk which loads DDR code and than a small boot application that prints to the UART works well.

We can even see the data loaded one time after the other (1k each)

by connecting with JTAG and seeing L2 and DDR memory of the booted DSP.

With messages we don't get any error.

but we can not even see the first message written to L2. 

Question: what is the limit on message size from rom boot code perspective ?

The changes we made before booting with messages -

we add a header of 4 Bytes - 2 for size of current message (including the Header) and 2 are 0 - we don't want to add checksum.

we also now send in the first msg the boot entry and the section addr and section size within  the message data  

( as stated we can not see even this first message resulting in a write to L2)

In the next packets we add the 4 bytes header.

For big endian we assume we dont have to convert code to big endian since this is done by the boot code.

But we tried both (little and big)

Question - should we convert the code and headers or should we send it in little indian

Hope that sheds some light.

Regards 

Ilay

ilay

Also, is there a time out for the srio rom boot code?

since i am using printf and breakpoint in the loading DSP.

Hi Ilay,

I am attaching a sample code for srio messaging code. This should be run on the host side. The boot code is embed in the c file as boot data. Please see if this helps you out.

Thanks,

Arun.

1134.srioMsgBootLoop.zip

Arun thanks a lot!

We tried running the codeby
creating an empty ccs project and adding the file
using the default c6678 cmd file compiling in little endian
and than and running 6678 gel file and loading the code.

We can not see the code loaded to the booted target. 

A few notes:

- it seems that the boot_code array in the file
doesn't correspond with the expected boot table structure
since after the boto entry there is the section size, and before it 
there should have been the section address.
- where is the 4 byte header that should be added before each 
message  which  includes packet size and checksum?

-Question: in what way are we expected to use this code- is it ok to
bring the board up in rio boot confing
and than running gel init
and downloading this code through jtag?

-rio_sp_err_stat register is 0x00020202 and not  0x2 as expected
Running the Direct IO example this didn't prevent sending the sections
and running the application on booted device.
so we don't think this is an issue and we just changed the code
to let it run,  by changing this line.

Tks
Ilay 

Hello Arun

about the zip above- still need some help to be able to use it.

Can you supply a bit more info on how to modify the example above to create

a srio boot paramtable table that can be burned to the nor flash and than read when loading the evm in spi boot mode ?

i assume i will have to change the .c file, the .cmd file

would the steps than be:

compiling using the make file

running the bat file to create the swapped bin file

writing the bin file to the nor flash

power cycliing the evm in spi boot (not i2c! with ibl)

running my application to load the code through srio messaging in 4x?

Just to update :

Srio boot

Problem of Srio messaging was solved. we can now boot using type 9 messages.

The problem was due to input and output error both on the Dsp that send the code and the one that receives it.

This was solved by stopping both dsp after bring up , and also after srion init

and verifying that Address 0x290b158 has a value of 0x00000002

which means port OK

if the value was different we tried to write the same value to reach a value of 0x0000002

For example if the value was 0x00020202 we write 0x00020202 to the register and most of the time it changes to 0x00000002

we susspect the erros might be from the fact the dip switch of the dsp sending the code was set to srio boot

instead of no boot and than it actually inits the dsp srio twich at bring up and after loading the code and running srio init

After changes this we steal had input and output errors but more rarely.

Hope thats helps

Ilay