Boot custom bootloader for C6748

Hi Dean,

You can try to use U-Boot to start up your code.

1) It's small enough. In our case (Ethernet, NAND, JFFS2 etc support) its binary is around 260KB (unpacked, ready to run).

2) It has a lot of flexibility to re-arrange your boot parameters. U-Boot environment is stored also in FLASH and can be used to guide the boot process. Using scripting you can perform some additional actions before booting main application. For example, we used to boot FPGAs before we continue loading linux on our C6424.

3) Using U-Boot it is possible to speed up SPI data transfers. Today's SPI memories can transfer data up to 40 MBps so it may take only 4-5 seconds to load. Most probably you will need to use EDMA coupled with McBSP to perform faster.

4) U-Boot comes with tools one of which is called 'aisimage'. I have added some support for C6000 family so now it can work for DSPs. Preparing AIS image is one of the steps in building U-Boot.

5) U-Boot is a linux project. It is built using free C6000 Code Sourcery toolchain, see the http://linux-c6x.org for details.

The guy who made first U-Boot port to C6000 had a board with C6745. He had submitted his work to U-Boot oficial repository. So you can try.

As for me I had a lot of work to re-arrange that code to support all memvers of C6000, not only C67x. However, this work is not published yet because of not fully tested.

Vladimir.

Thanks for the suggestion, but I should have said in my original post that we are using SYSBIOS, not Linux.

After a Power On Reset, the TI bootloader runs out of the C6748 ROM.  It expects an AIS image loaded into the SPI FLASH starting at 0x000000.  This TI bootloader is going to run and boot my custom bootloader.  Most of my original questions are related to how this happens.  It doesn't matter if you use UBOOT or a custom bootloader, you still need to overcome the TI bootloader first.

Maybe I don't fully understand your suggestion.  After reading it again, you seem to imply that UBOOT can generate AIS "code".  Transferring the output from AISGEN (PLL setup, DDR2 setup, etc) would be a pain.  I'm hoping for a more straight forward method that would still allow me to use CCSv5 and AISGEN.

Thanks anyway.

- Dean

It does not matter what image you are going to boot, SYS/BIOS or linux. Lets have a look on my AIS config:

#
# MORS8 AIS HEADER SCRIPT FOR mkimage
# NOTE: all values are in HEX, NOT DECIMAL!
#

# Load EMIF settings for NAND + FPGA
EMIFA_C642X 00624388 00624388 0x3FFFFFFC 0x3FFFFFFC 0x101

SET 3 01c40000 5 0
SET 3 01c40004 01614130 0

# Load PLL1 settings
PLL_C642X 17 0 0

# Load PLL2 settings and DDR2 emif settings
DDR2_C642X 17 1 B 0 50006405 00978A32 26923209 0014c822 00000249

The way to AIS is as follows.

1) You build u-boot, an ELF32 ABI.

2) You make a simple binary using objdump utility, u-boot-bin. Note, that this binary image is linked for specific location in RAM.

3) You make AIS image by invoking 'mkimage' utility with a type of image set to aisimage. You supply config file to it (as I posted above) and get and AIS image.

We tried AISGEN but were not satisfied. It was a perl script that was too slow. mkimage is pretty much faster and can be automated. However, it does not support COFFs (parsing sections and putting them as a sequence of AIS load command blocks). 

Of coarse, you can start from scratch and write your own loader that will load SYS/BIOS application. However, there are some difficulties on this way.

1) Each time you will need to improve the loader, you will need either to plug emulator into the board or support secondary loader update in your final application. U-boot   lets you update flash using its own tools: tftp, xmodem etc. So, you need to use emulator just once, only to set up each new board.

2) It will be difficult to (re)configure your loader if something will need to be changed. For example, you want to produce boards with slightly different hardware options: memory sizes, external peripherals, clock settings of CPU and quartz etc. Compiling and supporting lot of application images with such a small but annoying differencies will be a nightmare. Instead, you can simply create an environment for each board where all this data will live. Each parameter can be changed before booting your application.

3) Sometimes you will realize that SYS/BIOS is inconvenient for big applications. Development is slowed down by slow build process, slow loading of code into RAM. It's difficult to split an OS image and applications. We got into this trouble a couple of years ago. Then we moved to linux, and U-boot and life became much more interesting. :-)

Vladimir

Vladimir,

I appreciate your comments regarding challenges you have faced in using AISGEN, SYS/BIOS, etc.

However, Dean mentioned that he is using the TMS320C6748, a C674x DSP only device.  There is not a port for u-boot nor Linux on this device.  SYSBIOS is the path.

Dean Hofstetter said:

2.  Is it possible to setup one CCSv5 project, and only have a "small" section bootable by the internal C6748 bootloader?  Basically I want to create a new text / data section that would only have basic initialization code (LCD for example), an image for the display, and then whatever other code I need to finish booting (SPI read).

3.  If #2 above isn't possible, do I need two separate CCSv5 projects?  One small one that contains my custom bootloader, and then the normal large project?  If this is the case, how do I prevent both .BIN images from wanting to load into the SPI FLASH at 0x000000?

To me, the more straightforward path is to use #3, ie. two separate CCSv5 projects.  One project would be your custom, small bootloader.  The 2nd project is your application project.  Your bootloader would then be responsible for the minimal setup to enable loading your application image as well as initialize the LCD interface and display a "splash screen".  The initialization of the device would now be split between your bootloader and your application for things like PLL setup, DRAM setup, etc.

The use of a 2nd bootloader, ie. your bootloader, has been employed by others to also potentially speed up the SPI interface before extracting the application image.  This can also assist in the overall boot time of the device.

Your bootloader would absolutely need to be placed into the SPI flash in the AIS format, as the C6748 ROM code expects it.  Again, once your bootloader is running, it is your choice if you want to implement the AIS formating for the application image.

BrandonAzbell said:

However, Dean mentioned that he is using the TMS320C6748, a C674x DSP only device.  There is not a port for u-boot nor Linux on this device.  SYSBIOS is the path.

Brandon, there is an u-boot port for C6745 device, so you are wrong.

Here is patch for oficially released U-Boot version 2012.04.01.

7827.u-boot-2012.04.01_c6745.patch.rar

ftp://ftp.denx.de/pub/u-boot/u-boot-2012.04.01.tar.bz2

However, this patch was implemented by some other guy who made a greate work as a pioneer. I had to re-arrange all his code and start with my own U-Boot arch/c6x/... subtree to support not only a 6424 device for now but also all C6000 sub-families in future. When he first posted me a message he had been trying to submit his work as an official patch. Unfortunately, I could not find this branch in U-Boot git repository to give you a direct link.

As for linux, there is also a port of linux to C6X. Much effort has already been made to prepare linux for C6X, however, some additional work is still needed to adopt single core devices. Since 674x is a superset of C64x+ and C67x, it won't be a much problem to build linux for C674x. Most probably, it is already done by that guy who built U-Boot for C6745.

Now I want to clarify my position. U-Boot is a standalone bootloader with many off-the-shelf options which are useful for development. You can use any OS to start, either SYS/BIOS of linux. All my suggestion for Dean was to try U-Boot as a second bootloader and not to re-write a final application.

The two CCS .out project option would be the most straight-forward minimal change approach. StarterWare uses that model. References:

http://processors.wiki.ti.com/index.php/OMAPL138_StarterWare_Booting_And_Flashing
http://processors.wiki.ti.com/index.php/Quick_Start_Guide_StarterWare_01.20.XX.XX_%28supports_C6748%29

The key bit is the use of the out2rprc utility to convert the .out to a .bin file. Greatly simplifies the bootloader.

U-boot is quite flexible and powerful but complex (when compared to bare metal). Like Linux, it takes some time getting familiar with it. A whole different work flow.

Vladimir, I appreciate your suggestion, and the details backing it up.  However, we have zero experience with UBOOT, or make files, or ABI format (all of our stuff has to be in COFF), etc.  If we get completely stuck using TI's Starterware example, I may have to re-visit UBOOT.

I have reviewed Brandon and Norman's suggestions, and have some more questions using the Starterware example.

1.  Both Brandon and Norman seem to think it is better to have our custom bootloader initialize the DSP (DDR2, PLL's, PSC, etc).  These are things that we've always let the AISGEN tool + DSP ROM bootloader take care of.  If we use the Starterware example, is it a requirement that our custom bootloader does this initialization, or can we still do it the "old way"?

2.  I've read the two links that Norman provided.  We will use the Starterware bootloader as a "seed" project to create our customer bootloader.  Our custom bootloader would be generated with AISGEN (.out  + AISGEN = .ais), and our main application would be generated with out2rprc.exe (.out + out2rprc.exe = .bin).  This makes sense so far.  We can't use the SFH tool to write these images into our FLASH.  Our MFG process requires pre-programmed FLASH parts.  Therefore, I need something to combine the .ais file with the .bin file to make one "master" .bin file.  I do understand that the .ais file needs to be loaded at location 0x000000 of the SPI FLASH, and have no idea where the .bin file should be located or how to specify its address.

3.  The first link from Norman says the Startware bootloader would need to be rebuilt if we want to port it to a custom hardware platform.  Well that is exactly what we are doing.  What needs to be modified?  I know of a couple modifications:  1) add LDC init and display splash screen  2) allow it to boot from 32MB.  I'm unsure of what else needs to be modified.

4.  Since I have two independent CCSv5 projects (Starterware bootloader + our main application), how do I prevent memory overlap?  For example, lets say I tell the Starterware bootloader to load into DDR2 starting at 0xC0000000.  How do I tell our main application that 0xC0000000 + some ????? length is off limits?  One idea is to configure L2 to be 100% RAM, and then load the Startware bootloader into that (hopefully it fits).  For our main application, configure L2 to be 100% cache.  That way the Startware bootloader only costs me SPI FLASH space and zero run time space.  Is this along the right track?

Thanks, Dean

Just an opinion. Never created my own first stage bootloader. My experience has been with either DSP bare-metal or DSPUBL/ARMUBL/U-Boot/Linux. Your line of thought sounds plausible. Brandon will probably have more authoritative answers.

If you are already letting ROM bootloader using the AISGEN header to initalize the hardware (eg. DDR), I see no reason why your bootloader couldn't do the same. Just move your AISGEN settings from your current app to the new bootloader.

Each CCS Project should have a linker command file that specifies where everything is located in memory. Your bootloader would have program and data both in L2 RAM. Your application would be in DDR2. If any memory is shared, the linker command file can be used to exclude each other. Nothing automatic. You'll have to manually ensure they don't overlap.

There are a few ways to split the SPI Flash between bootloader and application. The simplest way is to use hard-coded sizes for each. The bootloader would then be use a hard-coded address in SPI flash to look for the application. The StarterWare Bootloader is probably hard-coded to a specific address. One of the costomizations would be to move this address.

Combining the bin files might require a hard-written utility to pad the space between bootloader and application. The TI Wiki sometimes talks of utilities that take a AISGEN'ed bin and an .out. I vaguely remember that it's usually built into flash programmers.

In theory, your application might not have to change at all. It won't be AISGEN'ed and it will reside a little higher in SPI flash.

Dean Hofstetter said:

1.  Both Brandon and Norman seem to think it is better to have our custom bootloader initialize the DSP (DDR2, PLL's, PSC, etc).  These are things that we've always let the AISGEN tool + DSP ROM bootloader take care of.  If we use the Starterware example, is it a requirement that our custom bootloader does this initialization, or can we still do it the "old way"?

Sorry, I didn't intend to make statements that suggested you need to scrap using the AISGEN to initialize the DDR, etc.  Unless you find a need to modify the approach, using the AISGEN is still a valid means of intiialization.

Dean Hofstetter said:

2.  I've read the two links that Norman provided.  We will use the Starterware bootloader as a "seed" project to create our customer bootloader.  Our custom bootloader would be generated with AISGEN (.out  + AISGEN = .ais), and our main application would be generated with out2rprc.exe (.out + out2rprc.exe = .bin).  This makes sense so far.  We can't use the SFH tool to write these images into our FLASH.  Our MFG process requires pre-programmed FLASH parts.  Therefore, I need something to combine the .ais file with the .bin file to make one "master" .bin file.  I do understand that the .ais file needs to be loaded at location 0x000000 of the SPI FLASH, and have no idea where the .bin file should be located or how to specify its address.

Your application image should be located where your custom bootloader expects it.  I know this is a vague statement, but they need to be aligned and can be placed anywhere in the free area of the SPI flash.  Basically this implies mapping out the SPI flash to allocate a region of memory for the bootloader starting at 0x000000 of a size that you would believe the bootloader will consume and might grow to be (if you allow upgrades over time).  The application image would then exist in a separate area of your choice.

Dean Hofstetter said:

4.  Since I have two independent CCSv5 projects (Starterware bootloader + our main application), how do I prevent memory overlap?  For example, lets say I tell the Starterware bootloader to load into DDR2 starting at 0xC0000000.  How do I tell our main application that 0xC0000000 + some ????? length is off limits?  One idea is to configure L2 to be 100% RAM, and then load the Startware bootloader into that (hopefully it fits).  For our main application, configure L2 to be 100% cache.  That way the Startware bootloader only costs me SPI FLASH space and zero run time space.  Is this along the right track?

One method to tell the main application that 0xC0000000+(bootloader length) is to modify the linker command file to carve out that section of DDR2.

Your idea of using the L2 RAM for the bootloader is interesting.  Off the top of my head, it seems reasonable.  Once you branch to your application code, then configure the L2 as cache.

Brandon / Norman, thanks for the feedback so far.  The fog is starting to lift a little bit, as bits and pieces of this process become clear.  Here is my plan of attack so far.

1.  Use the Starterware bootloader as our seed project for our custom bootloader.  Since we will be using AISGEN on this project, remove any DSP initialization stuff that TI ROM already takes care of (DDR2, PSC, PLL's, etc).  I will also need to add our LCD init code (plus splash screen).  Finally I'll want to add support for it to boot from SPI FLASH greater than 16MB.

2.  I'll evaluate the customer bootloaders size, and maybe double or triple it for future expansion.  So SPI FLASH address 0x000000 to 0x??????? will be only be used for the custom bootloader.  The application code will start at 0x????????? and go to 0xFFFFFFF.

3.  I'll evaluate if the max customer bootloader size to see if it fits into L2.  If so, I'll configure the custom bootloader project to only use L2 and then have my application project switch L2 to 100% cache.  If not, I still may put some of the bootloader code into L2, and I'll carve out some area in the DDR2 that is only to be use for the custom bootloader.  For the application project, the L2 stuff takes care of itself because the application will use it as 100% cache, but the DDR2 reserved space will have to be manually be kept track of.

4.  My main application project doesn't really care where in SPI FLASH it resides.  As long as the custom bootloader knows where to start looking.  I don't think out2rprc.exe cares either where in SPI FLASH I put the binary.  Aside from telling my application project that DDR2 address range xxxxxxx to yyyyyyy is off limits (reserved for the custom bootloader), I don't think I need to do anything special.

5.  Use AISGEN (with the tabs configured for DDR2, PLL's, PSC, etc) to convert the custom bootloader project .out to .bin.  Use out2rprc.exe to convert the application project .out to .bin.

6.  Here is where I'm stuck.  I need something to take both .bins and make one master .bin.  The custom bootloader .bin would be first in SPI FLASH starting at 0x000000.  Application .bin would get loaded at some pre-dermined offset in the SPI FLASH.  It appears that the Starterware tool SFH already does this.  Who wrote this, and can they chime in on this problem?  I'm not a windows programmer (embedded only), so creating some program to do this won't be possible.

We're getting closer.  If I can get #6 resolved, I can begin work on making this happen.

- Dean

Hi Dean,

Some notes to your steps:

1) You can implement a signature in your application image, some magic word at the start of image, image length and load address. Then you can add some scanning procedure to your custom bootloader which will try to find image start at several places in SPI FLASH, This will give you some freedom to save space that otherwise will be wasted as reserved for future.

2) Of coarse, L2 planning is totally appllication dependant but we have made some evaluations of C64x+ memory system performance. There are some interesing results. One of them is that time to copy memory from L3 to L3 (external DDR2 SDRAM) using standard C memcpy function is two to three times more than using EDMA to make two transfers,  first L3 to L2, then back L2 to L3. So, L2 turned totally into cache can potentially decrease performance of you application compared to the manual use of L2. Also, there can be no much performance decrease when you shift from full size L2 cache to half-size L2 cache, So, it can be worth of it. However, all these things will depend on your algorithms so only you can say definately.

Vladimir

Vladimir, thanks for the suggestions.  I might use your magic word suggestion.  Depends how the Starterware bootloader did their voodoo.  Interesting results on having L2 100% cache.  Not sure if you are aware of the silicon errata related to mixed L2, but you should check out errata 2.1.17.  Because of this errata, we've always ran L2 as 100% SRAM or 100% cache.  Our application is so big now, that 100% SRAM doesn't work anymore.  We have to be 100% cache.

Brandon / Norman, any luck with finding a solution to #6 above (take the two .bin files and make one .bin file)?  I was hoping whoever wrote SFH for Starterware / LCDK could help out with this.  Please reply if I'm on my own, or if TI can help out.

Thanks, Dean

I can't think of any utility that does exactly combines two binary files into one binary file at arbitrary offsets. Easy enough to concatenate two files. The hard-part is padding out the first binary such that the second starts at an arbitrary address. Linux has a few utilities like objcopy that might pad out the first. Some Windows variants have fsutil. In any case, it would require several utilties to get what you want. I think the easiest way would be to write a simple hard-code utiliy yourself. Shouldn't be more than 100 lines of C. I'm not familiar enough with TI's many utilities to comment.

I believe the TI flash programmers handle the two files as separate transactions. I don't think they merge the binaries into one and program once. Perhaps your production programmer can program two files? Yeah, that would change the production process. Programming two files would avoid wasting time programming the empty space between the two images.

Hi Dean,

Norman is right the sfh tool can accept multiple bin files as in the case of booting uboot wherein a ubl code initializes the the device and copies uboot into device memory but it treats the two input file as separate flash transactions. Please refer to the -flash option of the sfh as shown in the wiki article below:

http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138#Serial_Flasher_Options

This option by default  will write the UBL at offset 0x0000 and Uboot at offset 0x10000 (64K) in case of SPI flash. These offsets can be modified in the flashing tool and you can use them by rebuilding the serial flashing utility by using the instructions provided here:

http://processors.wiki.ti.com/index.php/Rebuilding_the_Flash_and_Boot_Utils_Package

In this case it is assumed that the UBL knows the offset in Flash where the uboot is written and will have the ability to copy it in memory based on the uboot header. The sfh tool inserts the uboot header to the uboot binary to inform the UBL about the size of the uboot and the load address location where it needs to be copied. In this case the ubl is in the AIS format and is loaded by the ROM while the uboot is a contiguous chunk of hex values(not AIS formatted) that is copied from flash to the memory . It This is possible because uboot doesn`t contain multiple sections in the .out and has just one continuous section that needs to be loaded in memory.

This is where things can get complicated in the UBL. If your application has multiple sections (.text, .bss, .vec etc) then your UBL will have to implement an ELF or a COFF binary parser and loader that can load each section in the right area of memory and you will need a utility that formats the application.out to a binary with uboot like headers associated to each section of the application binary.  This is where the out2rprc tool in Starterware will come in handy as it formats your application images as well as provides you the skeleton for the primary bootloader to parse that formated application file. To please your marketing team, you can put in your custom code into the Starterware bootloader code and get the screen to come up with the LEDs blinking from the boot loader and then let the rest of bootloader code from Starterware parse and load the remaining application binary.

Hope this helps.

Regards,

Rahul

Not much to add. On the C6748, you have the extra 128KB od memory, variously called L3 RAM, On Chip Memory, and Shared Memory. Not quite understanding the need for AISGEN for the "normal" project.

The approach you have outlined is sound.

I work with Dean and i am implementing this plan.

I tried to move c_int00 to the same address but i don't think the way i did it was the right way.  i used the wiki page 

http://processors.wiki.ti.com/index.php/Accessing_c_int00

this isn't doing what we want though. it is true that the portion if c_int00  living at the start of our DDR space is being overwritten, however when we call c_int00 at the end of the process we just go right back to main in the bootloader.  i am thinking sections .cinit and .bss need to be erased/overwritten as well but i am having trouble finding documentation explaining what i need to do. it would seem that all the data is appropriately placed but something needs to be done about the project symbols in order for this to work. any ideas?

I scanned over the c_int00 feature too quickly the first time. Lost a bit of the plot over all this time. I am not quite understanding the need for c_int00 to reside at the same place for both projects. Can't the two projects be totally separate? I was under the impression that the entry point was somewhere in the image header.  Custom bootloader in L2 RAM and application in DRAM. Only the LCD frame buffer in DRAM would overlap between projects. The transition between the two projects would probably require an orderly shutdown and restart of the LCD controller.

forget the LCD, that isn't important. we are looking to boot one project, unload the code for the next project and then loading the next project. we figured an easy way to do this is to overlap where c_int00 lives so when the first program loads we can load the c_int00 of the next project over the top of the first one so that when we call c_int00 at the end of the code load it will actually perform the c_int00 of the second project and the second project will be loaded.

The ROM bootloader must parsing AIS commands to initialize HW and to eventually jump to an entry point. Is it possible do the same in the custom bootloader? Use AIS command instead of c_int00?

it's kind of hard to use the AIS command when i am writing a C program

brandon, are you still paying attention to this post at all? Could you offer any help?

When I say AIS commands, I meant the AIS records that are defined in SPRAAT2E. These records are added by AISGEN when converting from .out to .bin. I assume that will parsing the AIS records as you read out the application .bin from SPI flash. I think the AIS records might be doing all the initialization of sections like .bss and .cinit.

If the application was not AISGEN'ed, then I can see how finding c_init00 is difficult. In cases where c_init00 cannot be hard-coded, a boot header containing c_int00 can be stored at a fixed location. With non-AISGEN binary image, I think the image is responsible for its own section initialization.

i am decoding the AIS gen of the main binary. i am not looking for c_int00, i already moved it so the linker already put it where i want. i am just shuffling code and i am trying to find out how to get the new c_int00 to execute the new program

Dean mentioned something about the custom bootloader starting at c_int00 in DDR2 then eventually running in L2. It that still so? I think it is easier if the custom bootloader loads and executed from L2 and the application loads and executes in DDR2. No overlap.

In theory, the new c_iint00 should be passed via one of the AIS Jump commands.

yes the c_int00 is loaded into DDR and then runs to L2.

i know WHERE the new c_int00 lives. THAT IS NOT THE PROBLEM. we overlapped the two c_int00 so that when the old program calls c_int00 it gets the NEW one for the NEW program. if they do not overlap then the old c_int00 will not get overwritten and all it will do is load the bootloader program over and over again. if i knew how to point the PC to the new c_int00 without using a function call so i could start executing the new program i wouldn't be on here trying to do it this way.

figured it out

appEntry = (void (*)(void)) entryPoint;
(*appEntry)( );

I also need to do something like this for my application. I understand the options. I have a couple questions.

Is there source code available anywhere for loading AIS files into memory?

Is there documentation of the file format generated by the out2rprc tool? I've looked at the starterware bootloader that handles these files and it looks like there's just a header that basically indicates start address, length and entrypoint. The bootloader just a contiguous block of memory from flash to DDR2. AIS is fairly complex. Is rprc really that simple?

No source code available for parsing AIS files that I know of.  See SPRAAT2E, section 4 for a description of all the AIS commands.

Never used the out2rprc tool.  We were breaking new ground before the Starterware stuff was available.  Hopefully some of the TI experts can weigh in on using out2rprc as another option.  I'd love to see a different way to do this, so I can compare it to our current steps.

- Dean

Thanks for the response. I was hoping ROM bootloader source was available. It is available on Freescale/Motorola DSPs. AIS does not look difficult to implement but then there's testing and debug and I worry about documentation completeness and correctness.

I will open a new thread and see what else I can learn about out2rprc.exe and the associated file format.

AIS code is available from a number of places:

1) As part of the flash programming utilities here http://sourceforge.net/projects/dvflashutils/ or here http://dvflashutils.sourceforge.net/. The code is rather complicated C#.

2) In the AISGEN install directory, there should be a C# file called AIS_Util.cs. It is not a stand-alone file. It appears to be an earlier verion of a file in the dvflashutils.

3) A Python port by Eliot Blenner Hassett
http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/119062.aspx
Eloit points out and fixes bugs in the dvflashutils implementation.

4) As a u-boot tools. See source tools/aisimage.* at the u-boot git.denx.de.

All of the code has some compatiblity problems as thay have to shadow the actual implementation in the ROM bootloader. All complicated by different behaviours with different versions of the ROM bootloader. If you are using you own bootloader, I guess that doe not matter. You can control both ends.