320c6424 UART boot - big endian

JimG,

I'm sorry nobody has answered your question yet.  I'm going to see if I can find someone in TI with some info for you since I could not find the info myself.  Stay tuned...

Brad

Bad news -- the UART boot mode won't work in big endian mode.  A documentation update is planned.  I'm told this is the only boot mode affected by endianness.

Thanks, Brad.  I suspect that there are other endian related problems surrounding boot.  For example, I have tried to generate a binary image for a program to go in EMIF flash from a big endian COFF file.

I found two problems.  The first of these is that despite the fact that I had indicated that it was an EMIF boot and that the width was 16, I did not get the required initial word with the value 0x00000001.  The content of the file began with the "magic value" word.  I suspect that this is a general issue with the genAIS program and not something specifically related to big endian.

The second problem, however, is that the generated binary file has the bytes in little endian order.  If EMIF boot does work for big endian, then I suspect that it would want to see the AIS script in big endian order.

I really feel like I'm swimming upstream here.  What's your opinion?  Are these tools, etc., going to work to build, boot and operate a big endian system?

There are a LOT more little endian users out there, so you're probably going to have more trouble this way.  However, if you need big endian then it might be worth the trouble.

Can you add the -debug option when you invoke genAIS and post your output here.  It will print whether it detects big or little endian in the out file.  Perhaps it's somehow detecting endianness improperly.  I assume you've set the compiler to build as big endian and that you are linking the big endian rts library, right?

Brad

I have genAis running from a cmd file, which in its turn runs at the end of my build.   I have included a fragment of the log file output that shows the genAIS execution.

After this had completed, I went to again check on the output file (mc4_boot.bin).  To my surprise, it contained some text that appears to be related to the genAIS debug option.  I examined this file with good old fashioned dos debug, but I'm sure that any other tool would show the same content.

I guess I'll want to avoid using the debug option when trying to generate useful outputs.

==================
output from genAIS:

[Linking...] "C:\Program Files\C6000Code Generation Tools 6.1.5\bin\cl6x" -@"Debug.lkf"
<Linking>

AisDebug.cmd

C:\Infinera\MC4\MC4_BOOT>\Perl\bin\perl ..\MC4_TOOLS\bin\genAIS.pl -i ./Debug/mc4_boot.out -o ./Debug/mc4_boot.bin -bootmode emifa -datawidth 16 -otype bin -crc 2 -debug
Invoking OFD6X, file
# File Endianness is big
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Calling calcCrc for Section :.text:
;;;     Section Size :0x00009520
;;;     Run Address  :0x10800000
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Calling calcCrc for Section :.switch:
;;;     Section Size :0x000000c8
;;;     Run Address  :0x1080cc6c
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Calling calcCrc for Section :.const:
;;;     Section Size :0x0000152c
;;;     Run Address  :0x10809520
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Calling calcCrc for Section :.cinit:
;;;     Section Size :0x0000017c
;;;     Run Address  :0x1080caf0
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
   AIS File Generation Complete

===============================
The generated file mc4_boot.bin

C:\Infinera\MC4\MC4_BOOT\Debug>debug mc4_boot.bin
-d 100
13AC:0100  23 20 46 6F 75 6E 64 20-65 6E 74 72 79 20 70 6F   # Found entry po
13AC:0110  69 6E 74 2C 20 65 6E 74-72 79 20 70 6F 69 6E 74   int, entry point
13AC:0120  20 30 78 31 30 38 30 39-33 36 30 0A 3B 20 4E 75    0x10809360.; Nu
13AC:0130  6D 62 65 72 20 6F 66 20-53 65 63 74 69 6F 6E 73   mber of Sections
13AC:0140  20 69 6E 20 4F 75 74 20-66 69 6C 65 2C 20 31 34    in Out file, 14
13AC:0150  0A 3B 20 53 65 63 74 69-6F 6E 20 4E 61 6D 65 73   .; Section Names
13AC:0160  0A 3B 20 4E 75 6D 62 65-72 20 6F 66 20 53 65 63   .; Number of Sec
13AC:0170  74 69 6F 6E 73 20 46 72-6F 6D 20 58 4D 4C 20 66   tions From XML f
-quit

JimG,

For now you might want to make your otype ascii to make it easier to read (i.e. you can open in any text editor).

Also, I figured out how to make 0x00000001 appear at the beginning.  Don't ask me why, but if you make bootmode "emif" instead of "emifa" it appears to generate the number for the width at the beginning.  I happened to notice that the example shipped with it was using that as the boot mode.  Maybe see if you get further with the booting that way...

Brad

Brad,

I spent the better part of the day constructing and running tests.  In little endian mode, I have been able to get UART boot and EMIF boot working properly with the genAIS script as part of my overall build procedure.  In big endian mode, I have had no success whatsoever.  I've even gone so far as to try doing byte reversals on the genAIS outputs. That doesn't work either.

I know that you have earlier indicated that although UART boot doesn't work big-endian, other modes do.  I am interested in the EMIF mode, with a flash on the EMIF bus, and an AIS script in the flash.  Do you know of any example that makes this work?  By example, I mean a procedure that starts with a C program and prepares it as an AIS script, ready for programming into the flash.

Absent a real example, I'm going to have to believe that boot doesn't really work big endian.  That will lead us to a fair amount of recoding in the parts of our system that handle communications with our big endian correspondents.  Before we take that step, I want to be really sure that big endian isn't going to be a good option for us.  And, of course, I would be delighted if a working example could show me that my testing has been in error.

Can you help us get clarity on this point?

Thanks, in advance.  We really appreciate the time that you have been putting into this.

Hi Jim,

Sorry to hear this is such a time consuming process.  I've been trying to find someone at TI that might have already gone through this procedure, but unfortunately I have not found anyone!  Like you, I'm not convinced that big endian AIS boot is feasible.  That said, here are the options:

1. You can switch to little endian.  In that case your boot issues become easy but you'll have some work to do on your application/algorithms.
2. Take advantage of "direct boot" from the EMIF.  In this scenario the EMIF will just start executing code directly from flash.  You would have to write your own bootloader for this scenario, but on the plus side, I'm sure you would be able to make it work as a big endian device.

FYI, method 2 would be very similar to the way we used to boot all devices, i.e. write your own bootloader.  You might want to read the app note, spra999, which covers that topic for our older c6000 devices.  The only difference would be that in the old devices the first 1k of flash would get copied to internal RAM and executed, but in this case you would be executing directly from flash.

Brad

Thanks, Brad.

I'm not sure what we're going to end up doing.  I'll have to take it up with the other members of the team.  We actually do use a boot loader of our own, already.  In the past, we have always found it easier to load these things with boot scripts into RAM.  That way, the code we are developing the product can also be loaded and tested with a debugger.  Debugging requires a little bit of rebuilding if you are planning to run from flash.

In the meantime, though, I have been running some other experiments.  Direct Boot definitely works.  Our boot loader can run from flash and it can load our main app.  All in big endian.  The main app runs fine big endian, including DSP BIOS and NDK.

We still have a mfg problem, though.  We wanted to use a UART boot to load a program that would in its turn initialize all of our flash images.  If we want to do that, it appears that we will have to reconfigure temporarily to little endian, and that this flash preparation program will have to do some gyrations to assure that the flash images it writes are correct in big endian mode.  A little unpleasant, but it seems possible.

With this in mind, I started to do some more experiments with UART boot little endian.  I have found that an AIS script prepared with the PLL1 function in it gets a "DATA CORRUPT" message from the boot loader.  The portion of the script with the PLL1 function was transcribed from the app note, so I'm reasonably certain that it was correct.  However, if I exclude this function, leaving in functions to set EMIFA and DDR2, I can get a program to load into DDR2 and execute.

There really seems to be a lot of little stuff in BOOT and genAIS that doesn't work.  I think it might be wise for a TI engineer to put in some test time on this.  At a minimum, it would be good if you could document the situation.  If I'm wrong about my findings, you would probably end up with examples that you could add to your app note to keep people from making similar mistakes.

Jim,

I agree that we badly need someone to look this stuff over.  Unfortunately with the current economic state we are pretty tight on resources.

I've been doing some poking around and have seen several other reports of people having issues related to the CRC option.  You may want to turn that one off.

Brad