Dual Boot : UBL

Perhaps I should start with the reason why I am trying to develop this dual boot loader. Perhaps someone could suggest a better way to implement my task.

I have an existing design with the C6713B. It is an embedded product that runs a high-speed control algorithm that fits entirely in the internal ram. It does not use DSP BIOS. I am redesigning this product to take advantage of the newer C6747 and I would like to port this code with as little modification as possible.

I want to add a feature so the end customer could upgrade this control algorithm with an image that I can email to him. I want the customer to be able to copy the image from his PC to a USB-Stick, plug that USB-Stick in to my product and have it burn into flash.

I have developed the program that can read the DSP-Image file from the FAT-32 USB-Stick and burn the the image into flash. This program uses DSP/BIOS, the USB Drivers, RTFS, etc. It uses about 4-Meg of RAM when it runs. My control algorithms are free from all of this overhead and run in about 130Kbytes of the fast internal DSP RAM.

My thought was that when the customer wants to upgrade the system, he could insert the USB-Stick, flip a switch to upgrade-mode and hit the reset button. This would boot the upgrade program that would read the USB and burn the flash. Then he would set the switch back to run-mode and hit the reset button again and the new control algorithm would run.

Is there something flawed in this approach?

Hi Dan, thanks for the detailed description.

What you are doing is the right method. You will need a DSP UBL which checks a GPIO and loads either your regular boot image or the special flashing one.

I'm not sure you are using the correct UBL source. What version of the OMAP-L137 SDK have you downloaded? The 3.20.00.xx version comes with ARM and DSP UBLs located in the src/boot-strap directory.

Thanks

Jeff

The project that I am compiling is here:

C:\CCStudio_v3.3\OMAP-L137_FlashAndBootUtils_2_20\OMAP-L137\CCS\UBL_DSP\UBL_SPI_MEM.pjt

I searched my hard-drive and i don't have a boot-strap directory.

I have a lot of difficulty finding things on the TI web-site, were do i get SDK version 3.20.00.xx ?

When I click on the link Software Development Kit (SDK) for OMAP-L1x and TMS320C674x Devices

I go to a page with;

message.

I can find :

OMAPL137 1_00_00_11 Product Download Page

Build date: 2009-08-27 16:05:45.116829000 -0700

 But this is very old.

The SDK can be downloaded here:

http://focus.ti.com/docs/prod/folders/print/omap-l137.html#toolssoftware

You will have to register and they wil send a link  to the latest files.

Jeff

OK, I requested the :

LINUXSDK-OMAPL137       Software Development Kit (SDK)

Linux Software Development Kit (SDK) for OMAP-L137/C6747 Processors

It will take several days for approval.

I just wanted to make sure that the UBL project that I want is in here because I am burning several days of development waiting for a Linux package when I won’t be using Linux.

Hi Dan, Ive done some testing and you can indeed use the UBL_SPI_MEM.pjt found in the CCS directory of the serial flashing tools. I ran into the same issue as you and after some debug found that some important lines were getting optimized out, which is why you would get hung at that location.

To solve this, remove the -o3 optimization from the project. You can do this by editing the .pjt file directly and removing "-o3" from the Compiler Options, or you can do it in CCS by right clicking the project, selecting "Build Options" and changing "Opt Level:" to "None".

Once you reflash your UBL it should work.

Now after further consideration, your method will be harder to implement. The UBL provided loads a monolithic binary to a fixed location, as you can tell from the source. So you cannot have a COFF file format with multiple sections that get loaded to different addresses. The UBL will just take the raw data and copy it to a given address in internal or external memory and jump there. So you have 3 options (in order of recommendation):

1) Modify the UBL to parse AIS files. In this scenario, you can create 3 AIS files (UBL, normal program, and USB flashing program) and flash them to different blocks of the SPI flash. Then depending on the GPIO, the UBL can start parsing the AIS Section Load commands from the correct SPI offset (either the normal program or the flashing one). After one of the programs is completely loaded, it can jump to the correct memory location and run.

2) Create monolithic binaries for both the normal program and the USB flashing program. In this case, the only modification needed to the UBL would be to check the GPIO and choose the correct place to load from flash.

3) In the UBL AIS file, also load some code that checks the GPIO and sets the bootloader SPI read address register (which we can tell you) to the correct offset. Then use the AIS Jump command to execute that  code before the bootloader loads either the normal program of the USB flasher. This is the most complicated option and would require use of the command-line AIS tool.

Jeff

Thanks Jeff,

That fixed the code from hanging.

 I am now trying to figure out why the boot-loader is jumping to entry point 0x00000000 instead of my entry point of 0xC000A658.

  ---  ...Start...   ---

C6747 initialization passed!

Booting TI User Boot Loader

        UBL Version: 1.65

        UBL Flashtype: SPI

.

Starting SPI Memory Copy...

Done with DEVICE_SPIInit(DEVICE_SPIBOOT_PERIPHNUM)...

Done with  SPI_MEM_open()...

About to start SPI_MEM_readBytes() Loop... Search for Magic Number...

currMemAddr = 0x00000000...

memorySize  = 0x00080000...

blockSize   = 0x00010000...

Valid magicnum, 0x55424CBB, found at offset 0x00010000.

   DONE

Jumping to entry point at 0x00000000.

  ---  ...Start...   ---

C6747 initialization passed!

Booting TI User Boot Loader

Naturally, jumping to 0x00000000 just starts running the boot-loader again.

when using SPIWriter_OMAP-L137:

When I specify my application, should it be the  "MyApplication.out"   file or an AIS image of that file? I have tried both.

When I specify the   “load address (in hex):”   I am using the memory map   .bss   location of    0xc0000000.

When I specify the   “entry point address (in hex):”   I am using the memory map  .cinit   location of    0xc000a658.

Is this all correct?

Even when I force the entry point to 0xC000A658, it does not look like it is going there. It is in a continuous loop, re-running the UBL.

  ---  ...Start...   ---

C6747 initialization passed!

Booting TI User Boot Loader

        UBL Version: 1.65

        UBL Flashtype: SPI

.

Starting SPI Memory Copy...

Done with DEVICE_SPIInit(DEVICE_SPIBOOT_PERIPHNUM)...

Done with  SPI_MEM_open()...

About to start SPI_MEM_readBytes() Loop... Search for Magic Number...

currMemAddr = 0x00000000...

memorySize  = 0x00080000...

blockSize   = 0x00010000...

Valid magicnum, 0x55424CBB, found at offset 0x00010000.

  spi_memboot.c -> SPI_MEM_BOOT_copy() -> gSpiMemBoot.entryPoint =  0x00000000

  spi_memboot.c -> SPI_MEM_BOOT_copy() -> gEntryPoint =  0x00000000

  Forced It :: spi_memboot.c -> SPI_MEM_BOOT_copy() -> gEntryPoint =  0xC000A658

   DONE

Jumping to entry point at 0xC000A658.

  ---  ...Start...   ---

C6747 initialization passed!

Booting TI User Boot Loader

        UBL Version: 1.65

        UBL Flashtype: SPI

.

Can you load the UBL in CCS using Load Program and step through the code (without any GEL file loaded)? Put a breakpoint at the end near the "Jumping to entry point" print statement and make sure it jumps to 0xC000A658. Make sure you initialized the DDR in AISGen if you are loading to DDR; otherwise the UBL will not be able to copy the program there.

Jeff

I have spent some time debugging this problem. I have compiled my application to run in SDRAM and in DSP-RAM. In both cases, the boot-loader can find the application in FLASH, copy it to the correct RAM location and jump to the entry-point. However, after stepping through only about 8-lines of application code, the program counter jumps back to the boot-loader code and winds up stuck in the   (start_c674x.asm)    abort: loop.

It might be a bad SDRAM data causing an invalid instruction. Once you get to your application code, before it jumps back to the boot-loader, if you manually Load Program does it then boot? If so that would indicate the application data is either not in the SDRAM correctly or got overwritten.

Jeff

What I did was step through the UBL code to the SPI_MEM_readBytes() function.

This function should read from the flash at location (gSpiMemBoot.memAddress =  0x00010014  ) :

• 0x00010000 is the Second block in the Flash. The first block contains the UBL, second block contains the application.
• 0x00000014 is 20-bytes into the block which gets you past the header.

And load (gSpiMemBoot.appSize = 148718) bytes (the size of my application), into memory location ((Uint8 *)gSpiMemBoot.ldAddress = 0xC0000000), the beginning of DDR.

However; when I look at what gets loaded into 0xC0000000 from this function call and what gets loaded into 0xC0000000 when I load the same program in CCS with Ctrl-L, they are not even close. If I load from CCS, the application runs correctly.

So I guess this function is not getting the correct data out of Flash and into RAM. I am assuming that the data in Flash is correct because the SpiWriter function that wrote the data into FLASH runs a verify and that verify passes.

Now, I am compiling the UBL project from the given source code and we have already determined that it does not work as shipped because of an incorrect optimization setting. In this package there are three UBL images. What is the difference between them and what are they used for? :

1. C:\CCStudio_v3.3\OMAP-L137_FlashAndBootUtils_2_20\ubl_C6747_SPI_MEM.bin
2. C:\CCStudio_v3.3\OMAP-L137_FlashAndBootUtils_2_20\ubl_OMAPL137_v1_SPI_MEM.bin
3. C:\CCStudio_v3.3\OMAP-L137_FlashAndBootUtils_2_20\ubl_OMAPL137_v2_SPI_MEM.bin

There is not one scrap of documentation that describes the use of these OMAP-L137_FlashAndBootUtils_2_20 utilities.

Would it be too much to have a readme.pdf that says “There are three UBL images in this directory. The first one is used for (xxx) purpose and has been compiled in (xxx) way so that it will (xxx). The second one is only to be used for (yyy) and the third one is for (zzz).”

Hi Dan, do you have a GEL file loaded when you connect to CCS? If so try removing it and loading your application. It is probably configuring the DDR for you.Try removing it and checking the results.

You can either add the DDR setup to your UBL or perform the DDR setup using the AISgen tool when converting your UBL to an AIS format file. The latter method is probably easier as no additional code would be needed. If you are unclear on the process of taking your UBL.out created in CCS and getting it to boot from flash, see this wiki for examples. You should be able to follow the same instructions but just use your own .out instead.

As for the UBLs, you should be using the one you were modifying in the CCS\UBL_DSP directory. The ones in the GNU directory are for booting Linux and restoring the default SPI flash as explained in the serial flashing wiki.

Jeff

I am a little confused about “configuring the DDR”. The EVM board uses SynchDRAM that is not capable of DDR (Double Data Rate). I have the AIS-Generator configured for the OMAP-L137 Development board which selects the EMIFB (SDRAM) checkbox.

SDCFG           = 0x00018421

SDTIM1          = 0x0E9129C8

SDTIM2          = 0x78080005

SDRFC            = 0x000003FC

So, I think my UBL AIS Image will configure everything correctly for the OMAP-L137 Development board and that configuration should remain when my app-code runs (please correct me if I am wrong on this).

 I have my LED-Blinking application now linked for DSP-RAM so I do not need SDRAM. This is how my real application will run.

 If I load my LED-Blinking application without a GEL file, it does not run because the PINMUX registers have not been set. I fixed this by configuring the PINMUX registers and the GPIO in my application. I can now power-on the board, load my app with no GEL-file and it will run. However, I still can’t get it to run from the UBL.

I modified the SpiWriter program to report (to CCS with printf) the first several words of the application data written into Flash.

I modified and the UBL program to report (to HyperTerminal) the first several words from the Load-Address.

SpiWriter Program Output

============

            ----- SpiWriter -----                            First 5-Words are header information

            appPtr[00]=55424cbb                         Magic Number

            appPtr[01]=11800a80                         Entry Point

            appPtr[02]=00005911                         App Size

            appPtr[03]=00010014                         MemAddress

            appPtr[04]=11800000                         LoadAddress

            appPtr[05]=000e00c2                          First Word of program

            appPtr[06]=4ddc0343

            appPtr[07]=00004fef

            appPtr[08]=00000067

            appPtr[09]=1143001c

            appPtr[10]=01080099

            appPtr[11]=0b801771

            appPtr[12]=00000000

            appPtr[13]=00000000

            appPtr[14]=0a800000

            SPI boot preparation was successful!

UBL Program

============

>>> gSpiMemBoot.magicNum  = 0x55424CBB

>>> gSpiMemBoot.entryPoint = 0x11800A80

>>> gSpiMemBoot.appSize    = 0x00005911

>>> gSpiMemBoot.memAddress  = 0x00010014

>>> gSpiMemBoot.ldAddress         = 0x11800000

============

Read the application into RAM for execution

         ----- First Words of program data. -----

         Ptr[0]=0x000E00C2

         Ptr[1]=0x4DDC0343

         Ptr[2]=0x00004FEF

         Ptr[3]=0x00000067

         Ptr[4]=0x1143001C

         Ptr[5]=0x01080099

         Ptr[6]=0x0B801771

         Ptr[7]=0x00000000

         Ptr[8]=0x00000000

         Ptr[9]=0x0A800000

    DONE

Jumping to entry point at 0x11800A80.

From this, I think I can conclude the application is being loaded into Flash correctly and read out of Flash into DSP-RAM correctly.

 Now if I load the UBL with CCS (No GEL-File), I can step through the last few line of code and it makes the jump to the correct Entry-Point (Address) of my application. If I continue to step through code, after only about 10-steps, the program counter jumps to 0x 020C1FD8 which is never-never land.

Can you use this debug GEL file to determine which silicon revision you have? Version 1.0 requires the KICK registers be unlocked to access the SYSCFG registers, so can you verify this is being done?

So after booting, you can connect to CCS and see your code being executed (using Load Symbols), but when you check the pinmux registers they are still not configured?

Jeff

I downloaded a binary file viewer so I can look at the MyLedBlink.out file (generated by CCS). It shows the first few bytes as C2, 00, 0E, 00. My debug code in the SpiFlash program and in the UBL program both show the same thing. After I step through my UBL, I can check memory at the load address and it is the same. The same is true if I go to the entry-point address. So I am correctly loading the MyLedBlink.out file into memory.

However; if I load that same (.out) file to my EVM board through CCS, those memory locations show very different data. CCS appears to be converting this file when it loads it into memory.

On my old C6713 system there is a third-party flash utility called FlashBurn. It used an executable called hex6x.exe to do some sort of a conversion on the out-file before loading it into flash.

Is there an equivalent conversion for this development system?

Another way of looking at this is:

This is the first couple of bytes (8-bit format) of the (app.out) file as viewed with the binary file viewer.

00000000  C2 00 0E 00 C1 A2 DE 4D 71 81 00 00 0F 01 00 00

00000010  1C 00 93 11 99 00 08 01 71 17 A0 11 00 00 00 00

00000020  00 00 04 00 00 00 60 10 80 11 00 00 80 11 00 00

This is the first couple of words (32-bit format) in memory after the UBL runs.

0x11800000    0x000E00C2

0x11800004    0x4DDEA2C1

0x11800008    0x00008171

0x1180000C    0x0000010F

0x11800010    0x1193001C

0x11800014    0x01080099

This is the first couple of words (32-bits format) in memory when CCS loads the program.

0x11800000    __text, .data, __data, edata, __edata, EVMC6747CPP_Type, .text

0x11800000    0x31F71247

0x11800004    0x20000591

0x11800008    0x2626AC45

0x1180000C    0x3001BC11

0x11800010    0x223C22E4

0x11800014    0x21BC52E6

0x11800018    0x00004000

Yes this is expected. As I mentioned before, the UBL is just doing a raw copy of data from your SPI flash to internal memory. It doesn't parse the COFF or AIS file format and load to the correct sections like CCS does. The solutions I gave were to change the memory map of your app.out where it is a monolithic binary file that can be loaded sequentially at a given address, or to modify  the UBL to correctly parse and load COFF or AIS file formats.

Jeff

My problem is that I don’t exactly understand what the COFF, AIS and monolithic binary formats are.

I know that the COFF is what CCS generates when I compile and link my code. However; in the past I either loaded this COFF  with CCS or burnt flash with the Flash-Burn utility and life was good.

The AIS file is generated from the COFF and includes boot-code and some register setup for memory and peripherals. It can be loaded into the beginning address of flash and the DSP will boot from it.

The Monolithic Binary is still a bit of a mystery to me. I have been trying to read about this but I still don’t know how to create one.

Can you point me to some resources so I can learn what I need to know?

Dan Lukas said:

My problem is that I don’t exactly understand what the COFF, AIS and monolithic binary formats are.

Let's go through them in order.

The COFF executable is what the compiler generates.  It consists of loadable code and data in sections, debug information, symbol and string tables, and extra metadata type stuff (date/time of generation, compiler/linker version used, etc).  There is a lot of extra stuff that one doesn't need for running a program.  When CCS loads an executable like this, it just goes and finds all the loadable data sections and copies them to their load-time addresses in the target's memory space (via the emulator).

The AIS file is a format that the ROM boot loader understands. To get from an executable (COFF) file to an AIS file, the AIS generator just takes out the loadable sections (code and data) from the executable and wraps them with AIS SECTION_LOAD commands, which also specify the load address and load size.  The AIS format also allows you to add a bunch of start-up initialization stuff (like external memory configuration, PLL/clock setup, etc.).  But all of the extra stuff that the COFF file held is now gone, so the AIS file will be smaller.

Now, the raw binary.  If you've used flashburn before, you may remember having to convert an executable to a HEX format (at least this what I had to do when I used it).  A raw binary is a lot like the hex format, in that it is stripped down to just the loadable code/data, but, unlike the hex format, it doesn't even contain addresses of where the data should be loaded.  It is just the data that should be placed in the target memory. So the information about where to load that data needs to be known or discovered in some other way. A bigger problem is what you do when you have a COFF file that has loadable memory segments that are not adjacent.  For example, if you have code being loaded to both internal L2 of the DSP (0x11800000) and the external DDR memory(0xC0000000).  Those regions of memory are multiple gigabytes apart, so if you try to generate a binary based on that, with the intention that the binary be loaded to the device and everything gets placed where it should, then the resulting binary would need to have gigabytes of filler in the image. So ideally, if you intend to use a binary format, you should use an executable that has all of its loadable sections linked to be adjacent in memory.  The u-boot binaries that are used in many of our ARM devices are like this.

So the point of this extended answer is that you will have to have a loader to be able to load the loadable sections of any executable you want to run.  The ROM boot loader is such a loader that can use AIS images for loading (which again are derived from the original executable).  The UBL programs we provide are binary loaders - that is, once they themselves have been loaded by the ROM boot loader, they run and try to load a monolithic binary image to some location in memory (that location is specified in a small header attached to the binary data).  If you are trying to load applications that are not suitable for being converted to binary form (because they have loadable sections all over the place in the memory map), then converting them to hex format might be an option, or converting them to AIS might be better. The format choice is up to you, and you will have to make sure that you write a loader/parser that can find the image and interpret its contents to get the loadable data where it needs to go. The only recommendation I have is that you do not use the original COFF executable, since it has a bunch of stuff you don't need and it is not trivial to parse the loadable data from the file format.

Regards, Daniel

Daniel,

Thank you for the detailed description. This is very helpful.

If I choose to write a Loader/Parser for AIS files, where do I find the document that describes the format of an AIS file?

I know how to generate and AIS file. I know how to generate a HEX file. How do I generate a raw binary file?

Dan

Dan Lukas said:

If I choose to write a Loader/Parser for AIS files, where do I find the document that describes the format of an AIS file?

This documentation can be found in the boot loader application note for the processor you are using(e.g. this one for the OMAP-L138).

This is actually a little trickier to answer. If you were using GCC for building ARM code, you would use the objcopy command.  If you are using TI tools for ARM or DSP, I would suggest you refer to this thread. Note that there is a hidden -b option for the hex6x or hex470 tools, but as George recommends, you should probably not use them.

Regards, Daniel

Daniel,

I got pulled-off onto another project for a little while. I am back working on my dual boot loader and you r last two emails have proved very helpful.

I have successfully modified the Spy-Writer program to burn the Flash with a UBL and two programs in different address areas of the flash.

I have successfully modified the UBL to read a DIP-switch and load one program or the other.

I used the undocumented –b option on Hex6x to create flat binary files the can execute from Flash.

So, I have been able to power-up the EVM and have it load and run either program depending on the position of the Dip-switch.

These are simple programs that do nothing but flash LEDs one direction or the other. One of the programs that I need to burn into flash uses the Real-Time File System, the USB Driver and DSP BIOS. It is too large and spread-out to create a flat-binary image of. I am now working on an AIS parser. If I don’t get disturbed with other projects, I should have something to report in a little while.

My UBL can now:

• Go to the correct flash address, (based on the state of a DIP switch).
• Look for and read the Spi-Writer header, (to get size and entry-point).
• Parse this area of Flash for “Section Load” commands and copy the loadable sections to the correct RAM addresses.
• Jump to the entry-point.

If no AIS commands are found, the UBL assumes this is a Flat-Binary and loads all data to the Load-Address specified by the Spi-Writer header.

The main problem that I am having is that the jump to entry-point does not always successfully run the program. This is a problem for both AIS files and Flat-Binary files. Sometimes the program hangs and I have to hit the reset button or cycle power for it to run correctly.

Again, these are simple programs that blink LEDs. They run correctly if they are loaded from CCS and they run correctly when burnt into flash with no UBL (direct Boot).

So, I am thinking that there is something in the UBL that is messing things up. The UBL runs in shared RAM and the LED-Applications run in L2-RAM so they should not interfere with each other. Is it possible that the UBL is leaving a resource in a bad state? 

What happens when the program hangs? Can you connect in CCS and load the symbols for the program? Also check to make sure the pinmux registers are correct.

Jeff

My understanding of the boot sequence is that the UBL.ais file will contain “Function Execute” commands that will configure the PINMUX, PLL, EMIFB and PSC registers on boot-up.

I have the AISgen setup for EVM defaults. When the UBL jumps to the application, do these registers need re-configured?

I have tried (in my application) reconfiguring the PINMUX registers, I have tried not reconfiguring. The results seem to be about the same. I tried other PINMUX configurations (where I disable Audio, EMAC, SD-Card and any other thing that I am not using). The results still seem the same.

In all cases, when I power-up or hit the reset button, sometimes the LEDs will blink in the correct pattern and sometimes they will not blink at all. It is very random. It may work 5-times in a row or not work for 5-times in a row. When I look at the UART output, the debug text in the UBL always looks correct. It never fails running the UBL, only fails after the jump to the LED-blinking application. I do not have UHART debug info in the LED-Blink application.

The AIS parser that I wrote ignores “Function Execute” commands. It only loads the sections. I set the PINMUX registers with function-calls at the beginning of my code.

There are two other things that may be worth mentioning:

1. When I flip the DIP-Switch and hit the reset button to run the other program, HyperTerminal will report that it sees the DIP-Switch, it  will go to the alternate address in Flash and find the magic-number at the correct block and report that it is loading the correct program. However; when the program runs, the old LED pattern will usually run. I must cycle power to get the correct LED pattern to run.
2. When I run the UBL from CCS (no GEL file), the application always seems to run without crashing. However; problem #1 still exists.

I am still working on some of your other suggestions.

Sorry for the delay in writing back. I have been working on several other projects.

To summarize where I am at right now:

1. I have looked very carefully at PINMUX configurations. I have tried several configurations from the standard configuration for the EVM (Most peripherals on the board enabled), to the bare minimum of what I need for my project (EMIFB, GPIO for LEDs and DIP-Switches).
2. I have worked with different configurations of the Power-Sleep-Controllers (PSC0/PSC1). I now powered-down everything that is not needed.
3. My code configures the PLL correctly.

I do all of this in the UBL.

The UBL also reads the DIP-Switches and correctly decides which of the two applications to boot.

The applications are in AIS format and I have written a parser to look for “AIS_OP_sectionLoad” commands and load these sections into memory.

The results are that I still can not get the applications to run reliably when they are allocated to DSP_RAM (0x1180 0000) However; if I link these applications to either SHARED_RAM (0x8000 0000) or to SDRAM (0xc000 0000) the application run perfectly.

From this I figured the DSP_RAM must be powering up as Level-2 cache so I used the CLSR libraries in the pspdrivers_01_30_00_06 package to configure the cache registers correctly. This did not help.

So in general, it appears that my problem is specific to using DSP_RAM (0x1180 0000). My UBL is running in SHARED_RAM (0x8000 0000) and if I run my applications in SDRAM (0xc000 0000) or the lower half of SHARED_RAM (0x8001 0000) they run fine. If I try to run them in DSP_RAM (0x1180 0000) or even offset them into (0x1181 0000) they do not run consistently. When I power-up they may run or they may not.

When they do run, they naturally run much faster in DSP_RAM then they do in SHARED_RAM or SDRAM.

Good to know. Do you think you had some hardcoded addresses somewhere that used the 0x00800000 range? That seems like the only reason why it would fail when using the mirror location.

Jeff

No, the two programs that I was testing this with were very simple programs that blinked LEDs on the EVM-Board. I would boot to one program or the other based on a DIP-Switch that I read in the UBL.

I tested this with more complicated programs and it works as long as I don't use the mirror location. 

What is the exact reason for having the mirror location and do I risk having problems down the road by using the 0x0080 0000 location?

Again, as long as you are not hardcoding any addresses, the DSP shouldn't have any issues using either address.

Keep in mind that the ARM can only access the 0x11800000 address range, so make sure any ARM code uses that.

Jeff

"any address"?

There are plenty of places where pointers are assigned addresses of registers like this:

short EVMC6747_GPIO_setOutput( unsigned short number, unsigned char output )

{   unsigned int bank_id = ( number >> 5 );

   unsigned int pin_id  = ( 1 << ( number & 0x1F ) );

   unsigned int* gpio_out = ( unsigned int* )( GPIO_BASE + GPIO_OUT_DATA_BASE + ( bank_id * GPIO_BASE_OFFSET ) );

   if ( ( output & 1 )  == 0 )        *gpio_out &= ~( pin_id );  // Set to LOW

   else        *gpio_out |= ( pin_id );   // Set to HIGH

   return 0;

}

But, how else would you do this?

I don't have any DSPRAM addresses hard-coded.

As far as the ARM goes, I have it turned off. I My final design will use the C6747 not the OMAP.

Sorry, yes I mean "any address in that memory region". Obviously other addresses may be hard coded as in your example.

Jeff