TMS320C6657: Ethernet Boot Initialization Time

I should have mentioned, I am compiling and using the IBL code from mcsdk_2_01_01_04.  I was not initially able to do the same from the pdk_c665x_2_0_14, I'll try to figure that out again today.

Chris,

If you need to boot as fast as you can, I would recommend EMIF NOR/NAND based boot mode.

If you boot the IBL first through I2C, that is slow because PLL is in bypassed mode via ROM bootloader.

best regards,

David Zhou

I assume this means I would have to write a custom Bootp/TFTP bootloader (or copy the code from the mcsdk ) and load that into the NAND?  It's not clear to me what is in the NAND on a stock EVM.

Chris,

If fast Ethernet boot time is a requirement for you. You can find the C6657 EVM TRM from here:

https://www.einfochips.com/partnerships-and-alliances/device-partnerships/texas-instruments/tms320c6657-evm/#5-resources

best regards,

David Zhou

I have to say, now I am more confused than ever.  It seems to me that the EVM has bypassed or circumvented some of the raw boot modes available in the C6657.  If you compare table 6-64 in the C6655/C6657 Users Manual with the table in section 10.3.8.3 in the document

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#boot-mode-dip-switch-settings

they are quite a bit different.  I'm thinking the EVM does not support the EMIF NOR/NAND boot mode you referred to above.  There is no entry for the ROM NAND boot mode. 

When I try to set the DIP switches for ROM NAND, according to the C6657 TRM (not the EVM TRM), the processor seems to react randomly, I can't seem to debug the ROM code at all.  I was getting pretty good at debugging the ROM code when in one of the I2C boot modes, so this is definitely different.

Booting using any of the I2C boot modes, NOR, NAND, TFTP provides no gain over each other, as the stage 1 boot loader, which is common to all modes is what appears to be slow.  I was able to make a single stage bootloader, by taking the TFTP code out of the second stage and compiling it into the first stage.  This reduced the time from power-on to Bootp from 14 seconds to 4 seconds.  That helps, but I still feel that is slow.

The end goal here is fastest Ethernet boot time on our custom board (we are in the process of designing it).  So, I was trying to prototype boot methods on the EVM, but I feel like the EVM is not affording me all the options I'll have on the custom board. When designing a custom board, what would be recommended then to have the fastest boot time, which would load a TFTP bootloader?

I'd appreciate any comments or suggestions.

Thanks,

Chris

Chris,

If you look into C6657L EVM TRM, SW3 PIN 5:2, when it is 0011, it is NAND boot.

The link you have is not complete truth table which lists all combination, it is missing this scenario, that is: SW3 PIN 5:2 configured for 0011.

best regards,

David Zhou

Just to add: If you want to set the DIP switches for ROM NAND, you need to program NAND first.

regards,

David

Yes, I set the DIP switches as you mentioned, I programmed the NAND with the image from

C:\ti\mcsdk_2_01_01_04\tools\boot_loader\examples\i2c\nand\evmc6657l\bin

which now seems like that might not be what we want.  That's for I2C NAND, which is not ROM NAND.

The problem is when I did ROM NAND I was not able to debug it like I had in the past.  Stepping through the ROM code the stack seems to be constantly changing.   Eventually, when the ROM code executes a return, B3 is corrupted and it branches to some bogus address.  This is still when executing ROM code.  I used this same debugging process and never had an issue when I was working on the I2C TFTP boot.

Stepping ROM code I expected to eventually get to bootMainNand(), but it never gets there.  But, even if it did, I see that inside bootMainNand() is access to the I2C looking for NAND config data.  I was hoping to see if that worked, but I never get that far.

BTW, I am assuming that without a valid NAND image, the ROM Bootloader is going into the weeds before I can connect the debugger, so, I use the RSTCTL to software reset the processor, which takes you back to 0x20b00000 and the start of ROM code.  But perhaps something got corrupted.  So, would you have an image I could use to load into the NAND (using the nandwriter I presume) to help make this behave more sanely?

Interesting comment in nandwriter.c

/**************************************************************************************
 * FILE PURPOSE: NAND writer utility
 **************************************************************************************
 * FILE NAME: nandwriter.c
 *
 * DESCRIPTION: A simple nand writer using platform lib APIs to program the NAND flash
 *              with an image that the ibl can read.
 *
 ***************************************************************************************/

Maybe that only works with the IBL and not the ROM NAND.

Chris,

If you use ROM NAND boot directly, forget about I2C, or you are creating a problem unnecessary which wastes your time.

Yes, you need to have a valid NAND image which contains meaning application. I would suggest you just got a simple application to work first and then replace the simple application with your TFTP boot application.

Attached please find some example for you. Please read the document under doc folder.

/cfs-file/__key/communityserver-discussions-components-files/791/C6657_5F00_directROM_5F00_Boot_5F00_example.zip

best regards,

David Zhou

So, I've made some progress, but I'm missing something.  First, I need to backup to some previous work...

When I started this project, I was using the ROM Ethernet mode.  In this mode, the ROM sends a Bootp request and expects to be UDP'ed a boot program.  However, ROM code does not setup the DDR, so you have to have a boot program that runs only in internal memory. So, I made one.  This initialized the DDR, then sent another Bootp and the normal operation code could be downloaded.  That seemed to work, but since it uses UDP for the file transfer, it would occasionally fail.  So, this is why I started to use the ILB Ethernet, which also does a Bootp but then does a TFTP which is more reliable.  But it is slow.  So, I am trying now to get the NAND boot working.

So, based on your help above, which was exactly what I needed to get this far, I took my boot code I developed above, which I as I mentioned does work to download an image into DDR, converted it and loaded it into the NAND.  Great news, it actually seems to load and run.  I can step my boot code in internal memory and it seems to be doing everything right, except I never seem to get any packets out the ethernet port. 

I suspected that maybe I need to implement the PLL fix that the IBL was doing, so I tried that but no luck.  The lights on the ethernet jack are correct, but never blink.  A good clue to the problem is TXGOODFRAMES never counts, but TXCARRIERSENSE is counting.  So, it would seem to indicate an issue in the setup of the ethernet.  I suspect the ROM Ethernet and IBL Ethernet code was configuring something I am now missing in my bootloader code.  But since the EMAC seems to operating as expected and the ethernet jack shows the correct lights (other than no blinking) I am at a loss what could be wrong.

So, I was missing the phy bit being set in the platform_init call, so now TXGOODFRAMES and TXBCASTFRAMES are both incrementing every 5 seconds as expected, but still no bootp messages coming out.  No blinking light on the ethernet jack as you would see when it was working.  I've tried at 1G 100M and 10M with no difference.  I feel like I am so close....

Hello,

You are on the right track so far.

You need to debug your last issue. One suggestion is: dump the registers (PLL1, EMAC, SerDes) for the working case (no through NAND booting) and the non working case (through NAND booting) and compare them to see if there are any differences.

Best regards,

David Zhou