MSC8156EVM Boot-over-Ethernet

[TimeLord86]

Hi everyone,

I've been attempting to get a boot-over-Ethernet system working. I've enabled the DHCP and TFTP servers, and created the .s files for the boot.

However, I am having issues in communicating with the MSC8156EVM board. I set the values of SW2 for the BPRT of the RCWHR to 110 (RGMII1 + I2C), and I would expect the board to send a DHCP discovery packet. So far, however, there is no communication out of the board.

Any suggestions or hints at what I'm missing?

Cheers.

[AndrewinApps]

Two things I would look at based on your description:

1. Is your S-Record file all on 1 line? <This is a requirement - so no return carriages, etc>.

2. If you are not configuring anything in I2C, and have no specific code in I2C, then you should run RGMII boot without I2C.

3. What are you seeing when you run a packet sniffer?

Regards,

-Andrew

[AviDG]

Hey Andrew in Apps

I have the same issue , I build a new ROM that right now I can load to the MSC8156EVM board with the Code Warrior in debug mode , and it works fine .

Now I want to have the option to load it during boot with the Boot over Ethernet option .

could you please guide me- what the process to do it ? 

(SW2 DIP switch configuration and how to configure the RCW (reset configuration word) )

hope to get help soon 

Avi .

[TimeLord86]

Hi Andrew,

As far as I'm aware, the S record is all one file, however I'm not getting that far to know if that's a problem or not yet!

I've tried with both the I2C on and off- no difference in performance.

The packet sniffer shows literally nothing. I expect to see at least a DHCP request, and I'm not even getting that at the moment.Have I set the board up incorrectly?

Regards,

David

[AndrewinApps · Accepted solution]

Hi David and Avi,

Based on seeing nothing in the packet sniffer - I would assume that the EE0 pin is set to 1 (leaving the board in debug mode - preventing the device from booting).

Could you confirm the value of this dip switch?

If the dips are configured to boot from Ethernet (no I2C), and EE0 is set to 0 (which is ON, as ON==0 in our boards), then as you said, you should see DHCP requests coming in on your sniffer -

assuming that your computer is connected directly to the EVM card via a crossover cable, with your computer set up to a static IP address on that port, with the sniffer monitoring the port in question.

[TimeLord86]

Hi Andrew,

Thanks for that, that seems to have given me DHCP requests! It was the EE0 DIP switch I hadn't realised needed changing.

I now have another issue, in that when downloading a program from the TFTP server, the download timeout's. The s-record is all in one file, and there are no line breaks in the generated srec file.

From looking at wireshark, it does appear that data is being transmitted as a significant number of transfer and acknowledgments are being sent and received. What is the configuration at build time? Is it a release build or does it need to be something special or specific?

Cheers,

David

[AndrewinApps]

Hello David,

2 notes on this - there are related errata for Ethernet boot - one related to delay time and another to size.

For the DHCP Server and TFTP Server software - could you test with Weird Solutions DHCP Turbo and TFTP Turbo?

If this works - this means that the problem was an Ethernet boot errata related to timeout - and you will need a bootpatch.

Also - the maximum size for Ethernet boot is 32MB unless you implement a patch for this.

[TimeLord86]

Hi,

I now have the boot-over-ethernet process working. However with a sufficiently large file (in this case 432kb), I get a timeout error consistently on data packet 366. I suspect this is due to the boot program being too large for local memory, and needing to use the DDR.

As I said in another post, I removed all references to the DDR memory from the program, and retried, but the TFTP transfer still died at packet 366. With a small boot file (2kb), the TFTP transfer completes, but I can't tell if it was successful, as there is no output from the device at this stage. The amount of data transferred per packet is 512kb.

I tried debugging this by 'attaching' and 'connecting'  the JTAG to the MSC8156EVM board to see the boot error memory location (0xC0101C04) after the ethernet boot process had died, however I cannot access this as the attaching or connecting program will not suspend on program entry.

Does anyone have any experience in boot-over-ethernet and this happening with the MSC8156EVM board?

[AndrewinApps]

Hello TimeLord86,

Yes - your theory regarding memory setups is correct - if you try to access DDR - the program won't work. If you try to fit more than your memory footprint in M2, it will not work.

For the MSC8156, there is 1MB of M3 memory available - I would suggest trying to fir your pogram in here to test your boot flow process without getting memory issues.

I would also be testing wiht a single core application at first as well.

Regarding how to get errata - do you  have an NDA and a sales/FAE representative with Freescale? The Errata docs, etc are protected under this, so the appropriate sales rep should be able to get you access to this. 

Regards,

-Andrew

[TimeLord86]

Hi Andrew,

Thanks for the information r.e. Errata - I'll get that chased up at my end.

You say that I should be testing programs that only run on a single core as the master core has no access to other cores' M2 memory, but then how can I create an Ethernet loadable file without including the other cores information as well? When I tired to put one core through the sc100elf2XX utility with only one core information, the utility returns an error, so obviously I need all six .eld files for an Ethernet loadable srec.

Should I be adding #ifdef's of something to explicitely state to run on only one core or have I missed something entirely? 

Thanks for your continued help.

[AndrewinApps]

Hello David,

Regarding your question for me - see the How to.doc in the SC\StarCore_Support\I2CBoot\MSC815x-MSC825x\ folder. 

Thie LED application is a single core's ELD file.

Regarding doing this for multicore applications - we have a custom loader app that I mentioned before - that can be used to work around the M2 access limitation.

This script was created and tested on SPI boot - but you can modify to Ethernet boot as you see fit.

The flow is as follows:

1. Convert the 6 ELDs to a single .srec file (using sc100-elf2xx.exe)
2. Manipulate the .srec file to move all slave cores M2 memory blocks to DDR, and have a DMA transfer from DDR to slave cores M2 during boot (using sc100-srec2xx.exe)
3. Extract the new crt0_start value from the manipulated .srec, and use it when creating the SPI boot image (using I2CBoot.exe)

One of our designer's wrote a script (attached) that creates an SPI boot image out of 6 multicore 8156 ELDs. You can get the actual command lines from it, or you can get it to do all the work for you.

To run:

-          Make sure you have I2CBoot.exe, sc100-srec2xx.exe, and sc100-elf2xx.exe in the same dir as the script

-          Edit the script to change the values of rel_path to point to the dir of the 6 ELD files, and base_name to the name of core0 ELD (rest of ELDs are assumed to be c1_basename, c2_basename, etc.)

-          Double-click the script, or run from command prompt: cscript Create_boot_image.vbs [base_name]

Regards,

-Andrew

[AviDG]

Hey Andrew 

The outpout of the process at your post is a .txt file that need to be flashed to the eeprom .

This .txt file contains the data from the input .srec file , Well the problem is how to build a multicore project that will be a DDR initialization boot patch, so when the board will load from the tftp in Ethernet Boot mode it will be loaded to the DDR memory ...

(this would not be a problem if my project would have been under 512KB (the on board EEPROM size) )...

I opened a SR and ask for this DDR initialization boot patch but didn't got an answer yet .

Thank 

Avi 

[AndrewinApps]

Hello Avi,

That example I posted earlier generates a .spi file for SPI booting. So if you look in the vbs script - if you skip the last few steps and just take the srec file generated fromthe following command:

'Manipulate srec file for multicore boot
WSshell.run "sc100-srec2xx.exe -eth -arch msc8156 " & srec_tmpfile & " " & srec_file, 0, true

This should provide you with what you need for Ethernet booting a multicore project.

So this srec file (set up with no return carriages, etc) is what the TFTP server should provide to the EVM.

When I test Ethernet boot, I go in stages:

1st: I will test Ethernet boot using the simple single core LED flashing example in the CodeWarrior Install directory here:

         \Freescale\CW SC v10.1.x\SC\StarCore_Support\I2CBoot\MSC815x-MSC825x\Leds\

Then, test our bootpach:

Based on the DDR bootpatch I wrote for the MSC8156ADS, I've just generated a new bootpatch for the EVM's DDR.

Please find this bootpatch attached. Please burn this bootpatch for your EVM's I2C ROM using the standard I2C burner project.

Once this is burned, update your dip switches so that BP is set to "1", and re-test a program that should access DDR.

With this you can run Ethernet boot with the same single core LEDs program again. It should run as before. After this program runs, you can connect the CodeWarrior debugger to the EVM (without resetting it) with the CodeWarrior attach feature. When set up without running any configuration script, we can test reading and writing to DDR memory this way.

If successful, then we can move on to testing a simple (single core) project that uses DDR.

If that works, then finally, I move on to the final step: to try a multicore project, etc that uses the DDR DMA feature generated automatically in the SREC when we create a multicore SREC in the same way as is done in our VBS script I provided previously.

Please let me know if you need any further clarification on this process.

-Andrew

[AviDG]

Hey Andrew

1. I still can't find were is the BP dip switch on the EVM board .... 

2. I burned the bootpatch file you sent me to the EEPROM on the EVM board , BUT when I restart the board I don't see on wireshark the handshake with the DHCP server , and the board does not pull the srec file from the TFTP server .

3. I know that I configure the DHCP and TFTP with the right inputs because when I put JP1 on 1-2 pins and SW2 dip switch is set to : "10000001" (this configuration is for the Ethernet Boot that does not need to write to the DDR) I can see on wireshark that the board is pulling the file from the TFTP but it stuck on the 102 packet ...(probably because of the need for the DDR bootpatch)

What am I doing wrong ????

Thank you for the help

Avi . 

[AviDG]

Hey 

correction to paragraph 3 (typing mistake) : JP1 on 1-2 pins and SW2 dip switch is set to :"01111110" (this configuration is for the Ethernet Boot that does not need to write to the DDR) .

Avi .

[AndrewinApps]

Is your RCW SRC group set to pull the RCW from dip switches, or is it pulling the RCW from the I2C ROM?

If it's the latter, the user will have to update the txt file for the specific boot port needed (RGMII boot) and enable the BP bit as per the MSC8156RM.

-Andrew

[AviDG]

Hey Andrew 

My RCW SRC  on the EVM board as much as I realized is configured by the JP1 jumper , I set it to 2-3 pins  -----> pulling the RCW from the I2C ROM .

Then I edit the .txt file you sent me in the RCW field to : 

RCWLR : 0x03 0x33 0x00 0x00 

RCWHR : 0x04 0x06 0x18 0x01 

According to the MSC8256RM this configuration sets : 

BPRT - 0100 = boot from RGMII1 without I2C .

BP - 1 = enable bootpatch 

RM -1 = enable resetmaster .

Then I burn the .txt file into the EEPROM on the EVM board .

But I still do not see any  DHCP handshake  on wireshark .....

I tried to set the BPRT to 0110 = RGMII1 with I2C , but still nothing on wireshark .

Any ideas ???

Thanks 

Avi 

[AndrewinApps]

Hi Avi,

Perhaps you are seeing the same issue David saw earlier?

Do you have EE0 set to 0 or 1?

[AviDG]

Hey Andrew 

EE0 is set to '0' (I tried '1' too and got the same results  ....)

In the EVM board EE0 is SW1 first switch (as I described  before SW1 is set to "01111110")

??????

Thanks 

Avi

[AviDG]

Hey Andrew

I got the problem :when I changed the BP bit value to 0 meaning my RCWHR now is : 0x04 0x04 0x18 0x01 

the board is booting from TFTP but only the 101 first packets ....

As I understand this is meaning that the .txt file you sent me , containing the DDR boot patch payload dosent doing the DDR init correctly .....

Could you please chack again if it fits my MSC8156EVM board ????

Thanks 

Avi 

[AviDG]

Hey

I am developing code for the MSC8156EVM board .
As a start I developed a simple application - led toggling .
In debug mode using the Code Warrior with USB connection  to the board it works fine .
Then I tried to load it from the Ethernet port , using the Ethernet boot option for the board .
Using the sc100-elf2xx program I converted the 6 eld files into one .srec file and I configured the DIP switch on the board and worked according to the "MSC81xx Ethernet Boot Test" guide form freescale .
With wire shark I noticed that I works fine and all the packets were transfered to the board .

But the leds don't toggle......

I assumed there is some kind of configuration I lost on the way ...
Then I found at the StarCore forum a post from you that answer some one else with similar problem the he needs a Boot Patch so he could use the DDR on the board - is this my problem ? or something else....

https://community.freescale.com/message/78968#78968

I guess this souled work for me too...

Could you please help me make this work .

Thanks .

Avi .