My application will not run properly when I load it using my custom User Boot Loader (UBL)

Check out Section 12b "Booting from Flash" in the student guide for our C6000 Embedded Design Using SYSBIOS Workshop.

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

The code in the gel file only executes when you have CCS connected to your target, i.e. if you are dependent on gel code then it is not possible to boot without CCS.  The chapter I referenced discusses how to "migrate" that information from the gel file into your bootloader.

I am using CCS connected to the target to download and run my UBL.  The UBL then loads the application image from flash.  The GEL code should be running when I download and run the UBL using CCS.

When I boot from flash, it is with a UBL in flash that was prepared by AISGen.  I used AISGen to configure the hardware.  Won't the AIS commands take care of configuring the hardware?

Zachary Hilbun said:

When I boot from flash, it is with a UBL in flash that was prepared by AISGen.  I used AISGen to configure the hardware.  Won't the AIS commands take care of configuring the hardware?

Yes, the AIS commands can be used to configure the hardware.  You must make sure that your gel file is configuring things the same way as AIS.  There is clearly a difference between what you're doing in the gel file and what you're doing in the AIS.

Just as a quick guess, make sure you do NOT enable PSC1 Module 8 (SATA) through the AIS tool.

If things are not working you need to do some debugging to understand where the issue is occuring.  Some tips for debugging boot issues are given on this wiki page:

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

"There is clearly a difference between what you're doing in the gel file and what you're doing in the AIS."

When I debug the UBL by downloading it through CSS it is using the same GEL file as when the application works properly as a stand alone.  The only difference seems to be the fact that my UBL loaded it rather than CSS.

I was looking through my linker .map file to make sure I was actually extracting all the image that the UBL loads.  My UBL seems to be loading all I thought it was suppsed to, but I am wonder if I am getting everything loaded.  The length of my applications seems to be 00023e23 so I extracted len=0x30000 to make sure I got it all.  I was wondering about the vector parts of it.  I had assumed those were copied in by the code itself rather than being initialized data.  There is also a link output section called LINKER GENERATED COPY TABLES that I am not sure about.

Part of my link map:

  L3_CBA_RAM     80000000   00020000  00001000  0001f000  RW X
  external_ram       c0000000   08000000  00023e23  07fdc1dd  RW X
  IRAM                  ffff0000   00002000  00000368  00001c98  RW X

The command file for hex470.exe.

-b
-image
-zero
-memwidth 8
-linkerfill
-fill 0x00000000

ROMS
{
  FLASH: org = 0xc0000000, len=0x30000, romwidth=8
}

The vector data:

.vecs      0    ffff0000    00000040    
                  ffff0000    00000040     mutex_pe9.oe9 (.vecs)

.vectorTable
*          0    ffff0040    00000328    
                  ffff0040    00000328     mutex_pe9.oe9 (.vectorTable)

LINKER GENERATED COPY TABLES

__TI_cinit_table @ c001fe18 records: 2, size/record: 8, table size: 16
 .data: load addr=c001f918, load size=000004ea bytes, run addr=c001ee18, run size=00000afe bytes, compression=rle
 .bss: load addr=c001fe10, load size=00000008 bytes, run addr=c0013a50, run size=0000929c bytes, compression=zero_init

LINKER GENERATED HANDLER TABLE

__TI_handler_table @ c001fe04 records: 3, size/record: 4, table size: 12
 index: 0, handler: __TI_zero_init
 index: 1, handler: __TI_decompress_rle24
 index: 2, handler: __TI_decompress_none

I'm still trying to resolve this issue.  It seems to be very close to working in that I can use CCS to actually single step through the code that has been loaded and see it makes the right calls to SYS/BIOS.  Occasionally one of the tasks being created will run and display a message.  I don't see my breakpoints in the tasks being hit though.  There seems to be some detail that is missing that is preventing this app from fully working when it is loaded by my UBL.   If I load it directly though CSS, it works fine.

If you set a breakpoint at the beginning of all your tasks I would expect that breakpoint to be always hit (once).  Is that correct?

Once you get inside the while loop of your task I imagine you have a call to TSK_sleep or SEM_pend in there.  Is the issue you're seeing that once you hit once of those calls that control never comes back to the task?  If you never return from TSK_sleep then I imagine there was an issue in setting up the timer, e.g. it's not properly enabled in the PSC or something along those lines.  If you're having an issue with SEM_pend then I think you need to examine what is on the other side of that SEM_pend, e.g. is there an interrupt from a specific peripheral that is supposed to call SEM_post?  If so, it would appear that peripheral is not getting the necessary interrupt.  That could again be due to PSC or it could also be related to pin muxing.

FYI, this gel file here is non-obtrusive and can give you some quick visibility into your PLL configuration and PSC configuration.  You might want to try the "Run All" in your two different scenarios and compare the resulting outputs to see if there's an obvious difference in PLL/PSC configuration.

I have seen a few times when a task looked like it ran and output a diagnostic message to CCS.  When I set breakpoints at the beginning of the tasks, I don't see any of them hit though.  If I single step through the main routine, I see tasks, etc. being created ok, and then main disappears into BIOS_start. 

I am wonder if there is more to setting up SYS/BIOS than I have been doing.  All I do is copy the image into memory and then jump to c_int00.  How do things like interrupt vectors and other things get initialized?  Is there anything that needs to be done for SYS/BIOS  before the main routine is entered than c_int00 is not doing?

I am still working on this issue (see my above comments).  I can single-step through the main function of the loaded application, and see tasks being created.  Those tasks don’t seem to be running however.  My thought is that there is some detail of the setup for the app being loaded or for SYS/BIOS that I am unaware of.

Also, I am using the Texas Instruments XDS100v2 USB Emulator.  This is very slow.  It can take seconds to do a single step.  Is there something faster available?

Zachary Hilbun said:

I am still working on this issue (see my above comments).  I can single-step through the main function of the loaded application, and see tasks being created.  Those tasks don’t seem to be running however.  My thought is that there is some detail of the setup for the app being loaded or for SYS/BIOS that I am unaware of.

You need to compare the state of the processor between the working case and the non-working case.  I expect the issue is likely related to PLL configuration, PSC, or pin-muxing.  The only peripheral SYSBIOS uses is a timer.

Zachary Hilbun said:

Also, I am using the Texas Instruments XDS100v2 USB Emulator.  This is very slow.  It can take seconds to do a single step.  Is there something faster available?

The XDS100v2 is a low cost emulator.  If you want high performance then I suggest the XDS560v2.  What version of CCS are you using?  I believe the XDS100v2 emulator was significantly improved in CCS 5.1.

Brad Griffis said:

I expect the issue is likely related to PLL configuration, PSC, or pin-muxing.  The only peripheral SYSBIOS uses is a timer.

I am using the same GEL file for both the app alone (working case) under CCS and when I load it with my UBL (non woking case) under CCS.  Is it possible for the processor to be set up differently using the same GEL file?  I don't do any hardware setup in my UBL so as far as I know, the GEL file does it all.

I am using CCS Version: 4.2.4.00033.  It may not be possible to change so I might have to find a better emulator.  The XDS100v2 is $1,495.00.  Is there one that is better but not so expensive?

Zachary Hilbun said:

I don't do any hardware setup in my UBL so as far as I know, the GEL file does it all.

Why are you even loading/running UBL in the first place?  The purpose of UBL is to setup the PLL, DDR, and pin-muxing and then load u-boot (or your application).  So what purpose does UBL serve in your system?  If it has no purpose then get rid of it.

Zachary Hilbun said:

I am using CCS Version: 4.2.4.00033.  It may not be possible to change so I might have to find a better emulator.  The XDS100v2 is $1,495.00.  Is there one that is better but not so expensive?

You don't have to move your whole build environment to CCS 5.1.  Just use CCS 5.1 for debugging.  Install it on a separate PC or in a virtual machine if you're afraid of messing up your current build environment.  I don't recommend any other emulators, i.e. get the XDS100v2 for low cost or get the XDS560v2 for high performance.

Brad Griffis said:

Why are you even loading/running UBL in the first place?  The purpose of UBL is to setup the PLL, DDR, and pin-muxing and then load u-boot (or your application).  So what purpose does UBL serve in your system?

We aren't running Linux, we are running SYS/BIOS.  The UBL can boot 1 of 2 images that are in flash.  It picks the version that is the most recent and boots that one. 

I have run the diagnostic GEL file at the main function of my UBL and right before I jump into the loaded image (see the full dump below at end of post).  After that, I had a problem getting it to run fully.  I rebooted my computer, took the USB cable on and off, and cycled power to the Logic PD board but nothing seems to fix it.   The last line of output when it would not fully dump was:

ARM9_0: GEL Output: DEV_INFO_19 =ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output:
ARM9_0: GEL Output: -----

Another issue I have run into is when I enter the main function of the image being loaded by the UBL.  This application runs fine when executed directly through CCS.  It eventually disappears into BIOS_start after starting some tasks.  If I break the emulator after that, I get addresses such as 0xaf14, 0x78008.  I had done this before and thought I saw addresses in the SYS/BIOS, but I could have been confused about that or it just happened to be that at that time.  Those don’t seem to be legitimate addresses but CCS debug doesn’t detect that.  I believe it should detect it as I have set Scripts/AM1808 Memory Map/Setup_Memory_Map.  I am wondering if something isn’t initialized and the CPU is just jumping to random memory.

I have put the various files I thought you might want to look at below and separated them by multiple blank lines.

When building my UBL I did:

Defined SKIP_LOW_LEVEL_INIT, __TMS470__, UBL_SPI_MEM, AM1808.  I use AIS to initialize the H/W.

There is a line in the code that uses DA850 and C6746.  I did not define either of those.  I did define:
#if (defined(DA850) || defined(C6746))

My memory map for that area where the CPU is executing but I think it should not is:

Start Address 0x0
End Address 0x1BBFFFF
Atributes NONE

I generate the image the UBL is loading by:

hex470.exe arm.cmd -o=TestAccel.binary TestAccel.out

arm.cmd is:

-b
-image
-zero
-memwidth 8
-linkerfill
-fill 0x00000000

ROMS
{
  FLASH: org = 0xc0000000, len=0x30000, romwidth=8
}

I flash it using a USB to serial adapter on port 5.  Note that the image is being loaded by the UBL running in CCS but the image is being loaded from flash.  This image in flash is also the same Debug image, not Release, that I run through CCS.

sfh_OMAP-L138.exe -erase -p COM5
sfh_OMAP-L138.exe -flash -p COM5 -targetType AM1808 -APPLoadAddr 0xc0000000 -APPStartAddr c00117a4 UBL_SPI_MEM.bin TestAccel.binary

The top of my application link map is:

******************************************************************************
                  TMS470 Linker PC v4.9.2                     
******************************************************************************
>> Linked Wed Feb 08 10:26:11 2012

OUTPUT FILE NAME:   <TestAccel.out>
ENTRY POINT SYMBOL: "_c_int00"  address: c00117a4

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  L3_CBA_RAM            80000000   00020000  00001000  0001f000  RW X
  external_ram          c0000000   08000000  00023e27  07fdc1d9  RW X
  IRAM                  ffff0000   00002000  00000368  00001c98  RW X

The link command file for the app image being loaded is:

/*
 * Do not modify this file; it is automatically generated from the template
 * linkcmd.xdt in the ti.targets.elf package and will be overwritten.
 */

/*
 * put '"'s around paths because, without this, the linker
 * considers '-' as minus operator, not a file name character.
 */

-l"C:\Users\ZacharyH\Code\Test\TestAccel\Debug\configPkg\package\cfg\mutex_pe9.oe9"
-l"C:\Program Files\Texas Instruments\bios_6_32_05_54\packages\ti\sysbios\lib\instrumented_e9\sysbios\sysbios.lib"
-l"C:\Program Files\Texas Instruments\xdctools_3_22_04_46\packages\ti\targets\arm\rtsarm\lib\ti.targets.arm.rtsarm.ae9"
-l"C:\Program Files\Texas Instruments\xdctools_3_22_04_46\packages\ti\targets\arm\rtsarm\lib\boot.ae9"
-l"C:\Program Files\Texas Instruments\xdctools_3_22_04_46\packages\ti\targets\arm\rtsarm\lib\auto_init.ae9"

--retain="*(xdc.meta)"

/* function aliases */
/* ignore error about def and ref in the same file */
--diag_remark=10268
--symbol_map xdc_runtime_System_flush__E=xdc_runtime_System_flush__F
--symbol_map xdc_runtime_Memory_query__E=xdc_runtime_Memory_query__F
--symbol_map xdc_runtime_System_putch__E=xdc_runtime_System_putch__F
--symbol_map xdc_runtime_Registry_getMask__E=xdc_runtime_Registry_getMask__F
--symbol_map xdc_runtime_LoggerBuf_write4__E=xdc_runtime_LoggerBuf_write4__F
--symbol_map xdc_runtime_LoggerBuf_reset__E=xdc_runtime_LoggerBuf_reset__F
--symbol_map xdc_runtime_System_avsprintf__E=xdc_runtime_System_avsprintf__F
--symbol_map ti_sysbios_timers_timer64_TimestampProvider_getFreq__E=ti_sysbios_timers_timer64_TimestampProvider_getFreq__F
--symbol_map xdc_runtime_Startup_exec__E=xdc_runtime_Startup_exec__F
--symbol_map xdc_runtime_System_abort__E=xdc_runtime_System_abort__F
--symbol_map xdc_runtime_Text_matchRope__E=xdc_runtime_Text_matchRope__F
--symbol_map xdc_runtime_LoggerBuf_write8__E=xdc_runtime_LoggerBuf_write8__F
--symbol_map xdc_runtime_System_sprintf_va__E=xdc_runtime_System_sprintf_va__F
--symbol_map xdc_runtime_LoggerBuf_flushAll__E=xdc_runtime_LoggerBuf_flushAll__F
--symbol_map ti_sysbios_timers_timer64_TimestampProvider_get64__E=ti_sysbios_timers_timer64_TimestampProvider_get64__F
--symbol_map xdc_runtime_SysStd_putch__E=xdc_runtime_SysStd_putch__F
--symbol_map xdc_runtime_LoggerBuf_getFilterLevel__E=xdc_runtime_LoggerBuf_getFilterLevel__F
--symbol_map xdc_runtime_Error_getData__E=xdc_runtime_Error_getData__F
--symbol_map xdc_runtime_Memory_alloc__E=xdc_runtime_Memory_alloc__F
--symbol_map xdc_runtime_SysStd_exit__E=xdc_runtime_SysStd_exit__F
--symbol_map xdc_runtime_SysStd_abort__E=xdc_runtime_SysStd_abort__F
--symbol_map xdc_runtime_SysStd_flush__E=xdc_runtime_SysStd_flush__F
--symbol_map xdc_runtime_Error_raiseX__E=xdc_runtime_Error_raiseX__F
--symbol_map xdc_runtime_LoggerBuf_setFilterLevel__E=xdc_runtime_LoggerBuf_setFilterLevel__F
--symbol_map xdc_runtime_LoggerBuf_enable__E=xdc_runtime_LoggerBuf_enable__F
--symbol_map xdc_runtime_LoggerBuf_getNextEntry__E=xdc_runtime_LoggerBuf_getNextEntry__F
--symbol_map xdc_runtime_Memory_getStats__E=xdc_runtime_Memory_getStats__F
--symbol_map xdc_runtime_Error_init__E=xdc_runtime_Error_init__F
--symbol_map xdc_runtime_SysStd_ready__E=xdc_runtime_SysStd_ready__F
--symbol_map xdc_runtime_Registry_findByName__E=xdc_runtime_Registry_findByName__F
--symbol_map xdc_runtime_Log_doPrint__E=xdc_runtime_Log_doPrint__F
--symbol_map xdc_runtime_Memory_getMaxDefaultTypeAlign__E=xdc_runtime_Memory_getMaxDefaultTypeAlign__F
--symbol_map xdc_runtime_Text_putLab__E=xdc_runtime_Text_putLab__F
--symbol_map xdc_runtime_Registry_getModuleId__E=xdc_runtime_Registry_getModuleId__F
--symbol_map xdc_runtime_Registry_findById__E=xdc_runtime_Registry_findById__F
--symbol_map xdc_runtime_Gate_enterSystem__E=xdc_runtime_Gate_enterSystem__F
--symbol_map xdc_runtime_Registry_getNextModule__E=xdc_runtime_Registry_getNextModule__F
--symbol_map xdc_runtime_System_printf_va__E=xdc_runtime_System_printf_va__F
--symbol_map xdc_runtime_Text_cordText__E=xdc_runtime_Text_cordText__F
--symbol_map xdc_runtime_LoggerBuf_disable__E=xdc_runtime_LoggerBuf_disable__F
--symbol_map xdc_runtime_Registry_getModuleName__E=xdc_runtime_Registry_getModuleName__F
--symbol_map ti_sysbios_timers_timer64_TimestampProvider_startTimer__E=ti_sysbios_timers_timer64_TimestampProvider_startTimer__F
--symbol_map xdc_runtime_LoggerBuf_flush__E=xdc_runtime_LoggerBuf_flush__F
--symbol_map xdc_runtime_Registry_findByNamePattern__E=xdc_runtime_Registry_findByNamePattern__F
--symbol_map ti_sysbios_gates_GateHwi_query__E=ti_sysbios_gates_GateHwi_query__F
--symbol_map xdc_runtime_LoggerBuf_flushAllInternal__E=xdc_runtime_LoggerBuf_flushAllInternal__F
--symbol_map xdc_runtime_Error_check__E=xdc_runtime_Error_check__F
--symbol_map xdc_runtime_System_vsprintf__E=xdc_runtime_System_vsprintf__F
--symbol_map xdc_runtime_Text_putSite__E=xdc_runtime_Text_putSite__F
--symbol_map xdc_runtime_System_exit__E=xdc_runtime_System_exit__F
--symbol_map xdc_runtime_Error_print__E=xdc_runtime_Error_print__F
--symbol_map xdc_runtime_System_asprintf_va__E=xdc_runtime_System_asprintf_va__F
--symbol_map xdc_runtime_Registry_addModule__E=xdc_runtime_Registry_addModule__F
--symbol_map xdc_runtime_Registry_isMember__E=xdc_runtime_Registry_isMember__F
--symbol_map xdc_runtime_Error_getCode__E=xdc_runtime_Error_getCode__F
--symbol_map xdc_runtime_SysMin_putch__E=xdc_runtime_SysMin_putch__F
--symbol_map ti_sysbios_timers_timer64_TimestampProvider_get32__E=ti_sysbios_timers_timer64_TimestampProvider_get32__F
--symbol_map xdc_runtime_SysMin_exit__E=xdc_runtime_SysMin_exit__F
--symbol_map xdc_runtime_Memory_free__E=xdc_runtime_Memory_free__F
--symbol_map xdc_runtime_Startup_rtsDone__E=xdc_runtime_Startup_rtsDone__F
--symbol_map ti_sysbios_gates_GateMutex_query__E=ti_sysbios_gates_GateMutex_query__F
--symbol_map xdc_runtime_System_aprintf_va__E=xdc_runtime_System_aprintf_va__F
--symbol_map ti_sysbios_timers_timer64_TimestampProvider_rolloverFunc__E=ti_sysbios_timers_timer64_TimestampProvider_rolloverFunc__F
--symbol_map xdc_runtime_SysMin_flush__E=xdc_runtime_SysMin_flush__F
--symbol_map xdc_runtime_Gate_leaveSystem__E=xdc_runtime_Gate_leaveSystem__F
--symbol_map xdc_runtime_Error_getMsg__E=xdc_runtime_Error_getMsg__F
--symbol_map xdc_runtime_Memory_valloc__E=xdc_runtime_Memory_valloc__F
--symbol_map xdc_runtime_SysMin_ready__E=xdc_runtime_SysMin_ready__F
--symbol_map xdc_runtime_Diags_setMask__E=xdc_runtime_Diags_setMask__F
--symbol_map xdc_runtime_SysMin_abort__E=xdc_runtime_SysMin_abort__F
--symbol_map xdc_runtime_LoggerBuf_write0__E=xdc_runtime_LoggerBuf_write0__F
--symbol_map xdc_runtime_Text_ropeText__E=xdc_runtime_Text_ropeText__F
--symbol_map xdc_runtime_System_avprintf__E=xdc_runtime_System_avprintf__F
--symbol_map xdc_runtime_LoggerBuf_write1__E=xdc_runtime_LoggerBuf_write1__F
--symbol_map xdc_runtime_Error_getId__E=xdc_runtime_Error_getId__F
--symbol_map xdc_runtime_Error_getSite__E=xdc_runtime_Error_getSite__F
--symbol_map xdc_runtime_Memory_calloc__E=xdc_runtime_Memory_calloc__F
--symbol_map xdc_runtime_System_vprintf__E=xdc_runtime_System_vprintf__F
--symbol_map xdc_runtime_LoggerBuf_write2__E=xdc_runtime_LoggerBuf_write2__F
--symbol_map xdc_runtime_Text_putMod__E=xdc_runtime_Text_putMod__F
--symbol_map xdc_runtime_System_atexit__E=xdc_runtime_System_atexit__F

/* C6x Elf symbols */
--symbol_map __TI_STACK_SIZE=__STACK_SIZE
--symbol_map __TI_STACK_BASE=__stack
--symbol_map _stack=__stack

--args 0x0
-heap  0x0
-stack 0x1000

MEMORY
{
    IRAM (RWX) : org = 0xffff0000, len = 0x2000
    L3_CBA_RAM (RWX) : org = 0x80000000, len = 0x20000
    external_ram (RWX) : org = 0xc0000000, len = 0x8000000
}

/*
 * Linker command file contributions from all loaded packages:
 */

/* Content from xdc.services.global (null): */

/* Content from xdc (null): */

/* Content from xdc.corevers (null): */

/* Content from xdc.shelf (null): */

/* Content from xdc.services.spec (null): */

/* Content from xdc.services.intern.xsr (null): */

/* Content from xdc.services.intern.gen (null): */

/* Content from xdc.services.intern.cmd (null): */

/* Content from xdc.bld (null): */

/* Content from ti.targets (null): */

/* Content from ti.targets.arm (null): */

/* Content from ti.targets.arm.elf (null): */

/* Content from xdc.rov (null): */

/* Content from xdc.runtime (null): */

/* Content from ti.targets.arm.rtsarm (null): */

/* Content from ti.sysbios.interfaces (null): */

/* Content from ti.sysbios.family (null): */

/* Content from ti.sysbios (null): */

/* Content from ti.sysbios.family.arm (ti/sysbios/family/arm/linkcmd.xdt): */
--retain "*(.vecs)"

/* Content from xdc.services.getset (null): */

/* Content from ti.sysbios.hal (null): */

/* Content from ti.sysbios.knl (null): */

/* Content from ti.sysbios.timers.timer64 (null): */

/* Content from ti.sysbios.family.arm.arm9 (null): */

/* Content from ti.sysbios.gates (null): */

/* Content from ti.sysbios.heaps (null): */

/* Content from ti.sysbios.family.arm.exc (null): */

/* Content from ti.sysbios.family.arm.da830 (ti/sysbios/family/arm/da830/linkcmd.xdt): */
--retain "*(.vectorTable)"

/* Content from xdc.runtime.knl (null): */

/* Content from ti.sysbios.xdcruntime (null): */

/* Content from ti.sysbios.utils (null): */

/* Content from ti.catalog.arm (null): */

/* Content from ti.catalog.arm.peripherals.timers (null): */

/* Content from ti.catalog (null): */

/* Content from xdc.platform (null): */

/* Content from xdc.cfg (null): */

/* Content from ti.platforms.generic (null): */

/* Content from am1806 (null): */

/* Content from configPkg (null): */

/*
 * symbolic aliases for static instance objects
 */
xdc_runtime_Startup__EXECFXN__C = 1;
xdc_runtime_Startup__RESETFXN__C = 1;
TSK_idle = ti_sysbios_knl_Task_Object__table__V + 0;

SECTIONS
{
    .text: load >> external_ram
    .stack: load > L3_CBA_RAM
    GROUP: load > external_ram
    {
        .bss:
        .neardata:
        .rodata:
    }
    .cinit: load > external_ram
    .init_array: load > external_ram
    .const: load >> external_ram
    .data: load >> external_ram
    .fardata: load >> external_ram
    .switch: load >> external_ram
    .sysmem: load > external_ram
    .far: load >> external_ram
    .args: load > external_ram align = 0x4, fill = 0 {_argsize = 0x0; }
    .cio: load >> external_ram
    .vecs: load > 0xffff0000
    .vectorTable: load > 0xffff0040
    ti.sysbios.family.arm.arm9.mmuTableSection: load >> external_ram, type = NOINIT
    xdc.meta: load >> external_ram, type = COPY

}

The link control file for my UBL is:

-e boot

IRAMStart  = 0x80000000;
IRAMSize   = 0x0001FFFF;
DRAMStart  = 0x80000000;
DRAMSize   = 0x0001FFFF;

ASYNC_MEM_START    = 0x62000000;

INTERNAL_RAM_START = 0x80000000;
INTERNAL_RAM_SIZE  = 0x0001FFFF;

STACK_START = INTERNAL_RAM_START + INTERNAL_RAM_SIZE;

MEMORY
{
  ARM_I_IVT       (RX)  : origin = 0xFFFFD000   length = 0x00000020

  UBL_TEXT        (RWX) : origin = 0x80000000   length = 0x0000B000
  UBL_DATA        (RWX) : origin = 0x8000B000   length = 0x00000800

  UBL_BSS         (RW)  : origin = 0x8000C000   length = 0x00002000
  UBL_STACK       (RW)  : origin = 0x80010000   length = 0x00002000
  UBL_DRAM        (RWX) : origin = 0x80012000   length = 0x0000D000
  FLASH     (RW) : origin = 0x80200000 length = 0x20
}

SECTIONS
{
   flashsect : {} > FLASH

  .text :
  {
    *(.boot)
    . = align(4);
    *(.text)
    . = align(4);
  } > UBL_TEXT

  .data :
  {
    *(.const)
  } > UBL_DATA

  .bss :
  {
    *(.bss)
    . = align(4);
  } > UBL_BSS
 
  .ddr_mem :
  {
    . += 0x10000000;
  } run = UBL_DRAM, type=DSECT, RUN_START(EXTERNAL_RAM_START), RUN_END(EXTERNAL_RAM_END), SIZE(EXTERNAL_RAM_SIZE)
 
  .stack :
  {
    .+=0x0400;
  } run = UBL_STACK, type=DSECT, SIZE(STACK_SIZE)
  
}

The GEL diagnostic dump is:

ARM9_0: Output:  Memory Map Cleared.
ARM9_0: Output:  ---------------------------------------------
ARM9_0: Output:  Memory Map Setup Complete.
ARM9_0: Output:  ---------------------------------------------
ARM9_0: Output:  PLL0 init done for Core:300MHz, EMIF:25MHz
ARM9_0: Output:  mDDR initialization is in progress....
ARM9_0: Output:  PLL1 init done for DDR:132MHz
ARM9_0: Output:  mDDR init for 132 MHz is done
ARM9_0: Output:  AG @ 300MHz---------------------------------------------
ARM9_0: GEL Output:
---------------------------------------------
ARM9_0: GEL Output: |             Device Information            |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: DEV_INFO_00 = 0x0B7D102F
ARM9_0: GEL Output: DEV_INFO_01 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_02 = 0x0000001E
ARM9_0: GEL Output: DEV_INFO_03 = 0x00000011
ARM9_0: GEL Output: DEV_INFO_04 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_05 = 0x000003E0
ARM9_0: GEL Output: DEV_INFO_06 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 0-0-6415775-3-13-7
ARM9_0: GEL Output: DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 1,0,0,4040
ARM9_0: GEL Output: -----
ARM9_0: GEL Output: DEV_INFO_17 = 0x00030003
ARM9_0: GEL Output: DEV_INFO_18 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_19 =ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output:
ARM9_0: GEL Output: -----
ARM9_0: GEL Output: DEV_INFO_20 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_21 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_22 = 0x30303864
ARM9_0: GEL Output: DEV_INFO_23 = 0x3430306B
ARM9_0: GEL Output: -----
ARM9_0: GEL Output: DEV_INFO_24 = 0x0300700D
ARM9_0: GEL Output: DEV_INFO_25 = 0x0061E59F
ARM9_0: GEL Output: DEV_INFO_06 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_26 = 0x1F900001
ARM9_0: GEL Output:

ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |               BOOTROM Info                |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: ROM ID: d800k004
ARM9_0: GEL Output: Silicon Revision 1.1
ARM9_0: GEL Output: Boot pins: 30
ARM9_0: GEL Output: Boot Mode: Emulation Debug
ARM9_0: GEL Output:
ROM Status Code: 0x00000000
Description:ARM9_0: GEL Output: No error
ARM9_0: GEL Output:
Program Counter (PC) = 0x80007028
ARM9_0: GEL Output:
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              Clock Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output:
ARM9_0: GEL Output: PLLs configured to utilize crystal.
ARM9_0: GEL Output: ASYNC3 = PLL0_SYSCLK2
ARM9_0: GEL Output:
ARM9_0: GEL Output: NOTE:  All clock frequencies in following PLL sections are based
ARM9_0: GEL Output: off OSCIN = 24 MHz.  If that value does not match your hardware
ARM9_0: GEL Output: you should change the #define in the top of the gel file, save it,
ARM9_0: GEL Output: and then reload.
ARM9_0: GEL Output:
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PLL0 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output:
ARM9_0: GEL Output: PLL0_SYSCLK1 = 300 MHz
ARM9_0: GEL Output: PLL0_SYSCLK2 = 150 MHz
ARM9_0: GEL Output: PLL0_SYSCLK3 = 25 MHz
ARM9_0: GEL Output: PLL0_SYSCLK4 = 75 MHz
ARM9_0: GEL Output: PLL0_SYSCLK5 = 100 MHz
ARM9_0: GEL Output: PLL0_SYSCLK6 = 300 MHz
ARM9_0: GEL Output: PLL0_SYSCLK7 = 50 MHz
ARM9_0: GEL Output:
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PLL1 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output:
ARM9_0: GEL Output: PLL1_SYSCLK1 = 264 MHz
ARM9_0: GEL Output: PLL1_SYSCLK2 = 132 MHz
ARM9_0: GEL Output: PLL1_SYSCLK3 = 88 MHz
ARM9_0: GEL Output:
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PSC0 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output:
ARM9_0: GEL Output: State Decoder:
ARM9_0: GEL Output:  0 = SwRstDisable (reset asserted, clock off)
ARM9_0: GEL Output:  1 = SyncReset (reset assered, clock on)
ARM9_0: GEL Output:  2 = Disable (reset de-asserted, clock off)
ARM9_0: GEL Output:  3 = Enable (reset de-asserted, clock on)
ARM9_0: GEL Output: >3 = Transition in progress
ARM9_0: GEL Output:
ARM9_0: GEL Output: Module 0: EDMA3CC (0)        STATE = 0
ARM9_0: GEL Output: Module 1: EDMA3 TC0          STATE = 0
ARM9_0: GEL Output: Module 2: EDMA3 TC1          STATE = 0
ARM9_0: GEL Output: Module 3: EMIFA (BR7)        STATE = 0
ARM9_0: GEL Output: Module 4: SPI 0              STATE = 0
ARM9_0: GEL Output: Module 5: MMC/SD 0           STATE = 0
ARM9_0: GEL Output: Module 6: AINTC              STATE = 3
ARM9_0: GEL Output: Module 7: ARM RAM/ROM        STATE = 3
ARM9_0: GEL Output: Module 9: UART 0             STATE = 0
ARM9_0: GEL Output: Module 10: SCR 0 (BR0/1/2/8)  STATE = 3
ARM9_0: GEL Output: Module 11: SCR 1 (BR4)        STATE = 3
ARM9_0: GEL Output: Module 12: SCR 2 (BR3/5/6)    STATE = 3
ARM9_0: GEL Output: Module 13: PRUSS              STATE = 0
ARM9_0: GEL Output: Module 14: ARM                STATE = 3
ARM9_0: GEL Output: Module 15: DSP                STATE = 0
ARM9_0: GEL Output:
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PSC1 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output:
ARM9_0: GEL Output: State Decoder:
ARM9_0: GEL Output:  0 = SwRstDisable (reset asserted, clock off)
ARM9_0: GEL Output:  1 = SyncReset (reset assered, clock on)
ARM9_0: GEL Output:  2 = Disable (reset de-asserted, clock off)
ARM9_0: GEL Output:  3 = Enable (reset de-asserted, clock on)
ARM9_0: GEL Output: >3 = Transition in progress
ARM9_0: GEL Output:
ARM9_0: GEL Output: Module 0: EDMA3CC (1)        STATE = 0
ARM9_0: GEL Output: Module 1: USB0 (2.0)         STATE = 0
ARM9_0: GEL Output: Module 2: USB1 (1.1)         STATE = 0
ARM9_0: GEL Output: Module 3: GPIO               STATE = 0
ARM9_0: GEL Output: Module 4: UHPI               STATE = 0
ARM9_0: GEL Output: Module 5: EMAC               STATE = 0
ARM9_0: GEL Output: Module 6: DDR2 and SCR F3    STATE = 3
ARM9_0: GEL Output: Module 7: MCASP0 + FIFO      STATE = 0
ARM9_0: GEL Output: Module 8: SATA               STATE = 0
ARM9_0: GEL Output: Module 9: VPIF               STATE = 0
ARM9_0: GEL Output: Module 10: SPI 1              STATE = 0
ARM9_0: GEL Output: Module 11: I2C 1              STATE = 0
ARM9_0: GEL Output: Module 12: UART 1             STATE = 0
ARM9_0: GEL Output: Module 13: UART 2             STATE = 0
ARM9_0: GEL Output: Module 14: MCBSP0 + FIFO      STATE = 0
ARM9_0: GEL Output: Module 15: MCBSP1 + FIFO      STATE = 0
ARM9_0: GEL Output: Module 16: LCDC               STATE = 0
ARM9_0: GEL Output: Module 17: eHRPWM (all)       STATE = 0
ARM9_0: GEL Output: Module 18: MMC/SD 1           STATE = 0
ARM9_0: GEL Output: Module 19: UPP                STATE = 0
ARM9_0: GEL Output: Module 20: eCAP (all)         STATE = 0
ARM9_0: GEL Output: Module 21: EDMA3 TC2          STATE = 0
ARM9_0: GEL Output: Module 24: SCR-F0 Br-F0       STATE = 3
ARM9_0: GEL Output: Module 25: SCR-F1 Br-F1       STATE = 3
ARM9_0: GEL Output: Module 26: SCR-F2 Br-F2       STATE = 3
ARM9_0: GEL Output: Module 27: SCR-F6 Br-F3       STATE = 3
ARM9_0: GEL Output: Module 28: SCR-F7 Br-F4       STATE = 3
ARM9_0: GEL Output: Module 29: SCR-F8 Br-F5       STATE = 3
ARM9_0: GEL Output: Module 30: Br-F7 (DDR Contr)  STATE = 3
ARM9_0: GEL Output: Module 31: L3 RAM, SCR-F4, Br-F6 STATE = 3

Brad Griffis said:

Your boot mode is set to emulation debug. That's not correct for SPI boot.

I'm not sure I understand what you mean.  I am not trying to fully boot out of flash memory right now.  I have an image in flash memory, but I am debugging the UBL under CCS V 4 and it is reading the flash memory and then jumping into the application image it has copied into RAM.

Also, both the UBL and the application image I am loading are debug versions.

Is your UBL code handling the copy table and handler table that were generated by the linker?  I don't believe u-boot.bin would have such tables and so the code is probably not in the code you started with.  I think the issue is in your generation of the application image that you write to flash and the way in which UBL loads it.  Compare the RAM in the two cases where it works and does not.  I think you'll find that some of the sections (probably tied to the tables) is not being loaded by UBL.

Brad Griffis said:

Is your UBL code handling the copy table and handler table that were generated by the linker?

Do you have a link that describes doing this?

The function _c_int00 is entered before main is entered and it seems to be doing some copying.  I can't say whether it is correct or enough though. 

What are the names of the copy and handler tables?  I posted my link map earlier in case you need to look at it.

Brad Griffis said:

I don't believe u-boot.bin would have such tables and so the code is probably not in the code you started with.

Almost all the documentation I have seen has to do with loading Linux so that could be true.  I haven't really seen any documentation that talks about the copying you are referring to.

Brad Griffis said:

I'm not sure what the "handler table" is that you mentioned earlier though

I don't know what that is but you mentioned it in "Is your UBL code handling the copy table and handler table that were generated by the linker?".

Is there any web page that would tell me what needs to be copied other than the image itself?  If you look at my use of the hex470.exe command and the link control file, I think I am pulling out eveything that is in the RAM that is used by the code starting at c0000000.  My concern is that there are some tables somewhere that need to be handled in a special way by the UBL but I haven't seen any documentation on this.

You mentioned eariler that my sample UBL may have been intended only for Linux.  If there a sample around for non Linux?

In addition to the post above.  An issue I have is when I run hex470.exe. The results are below and the command file for this is described in the long post above which has linker data as well. I am concerned about the messages for "falls in unconfigured memory". This could be normal but I am unsure about it. It could be possible that this data is copied to it's final location by the code outide of the UBL.

C:\Users\ZacharyH\TI\Flash utilities>hex470.exe arm.cmd -o=TestAccel.binary TestAccel.out
Translating to Binary format...
   "TestAccel.out"   ==> .text
   "TestAccel.out"   ==> .const.1
   "TestAccel.out"   ==> .const.2
   "TestAccel.out"   ==> .cinit
   "TestAccel.out"   ==> .vecs
warning: section TestAccel.out(.vecs) at 0ffff0000h falls in unconfigured
   memory (skipped)
   "TestAccel.out"   ==> .vectorTable
warning: section TestAccel.out(.vectorTable) at 0ffff0040h falls in
   unconfigured memory (skipped)

Zachary Hilbun said:

C:\Users\ZacharyH\TI\Flash utilities>hex470.exe arm.cmd -o=TestAccel.binary TestAccel.out
Translating to Binary format...
   "TestAccel.out"   ==> .text
   "TestAccel.out"   ==> .const.1
   "TestAccel.out"   ==> .const.2
   "TestAccel.out"   ==> .cinit
   "TestAccel.out"   ==> .vecs
warning: section TestAccel.out(.vecs) at 0ffff0000h falls in unconfigured
   memory (skipped)
   "TestAccel.out"   ==> .vectorTable
warning: section TestAccel.out(.vectorTable) at 0ffff0040h falls in
   unconfigured memory (skipped)

Ah, yes, that's a problem...  I see now why that's happening.  Here's a copy/paste of your hex conversion commands for quick reference:

Zachary Hilbun said:

-b
-image
-zero
-memwidth 8
-linkerfill
-fill 0x00000000

ROMS
{
  FLASH: org = 0xc0000000, len=0x30000, romwidth=8
}

The hex conversion utility is documented in Chapter 11 of the TMS470 Assembly Language Tools Guide.  In particular when using the -image option it will create a file that corresponds to the address range specified in the ROMS area.  In this case you have specified only the 192KB of code from address 0xC0000000, so I expect you would get a 192KB image as a result.  I think in order to correct your problem you need to define a second ROMS area to correspond to your vector table at 0xFFFF0000.  This will result in a second output file from the hex conversion utility and your UBL will need to copy the contents of that file to the vector area.

Brad Griffis said:

This will result in a second output file from the hex conversion utility and your UBL will need to copy the contents of that file to the vector area.

I had looked at address 0xfff000 before and it looked like it had vectors in it, although I am no expert on that.  It complains about 2 vector areas .vecs and .vectorTable.  Do they both need to be copied to their respecitve addresses ( 0ffff0000h and 0ffff0040h) or just one?

If I wind up with multiple files, how do people go about flashing that many files?  The current image file is being flashed as bellow.  You wind up with a header in front of the .binary.  Is there a standard way for people to flash multipe images into flash?  sfh_OMAP-L138.exe seems to be setup with the assumption that there will be at most 2 fiees and each one will be in its own sector/block.

sfh_OMAP-L138.exe -flash -p COM5 -targetType AM1808 -APPLoadAddr 0xc0000000 -APPStartAddr c00116fc UBL_SPI_MEM.bin TestAccel.binary

As far as I know, sfh_OMAP-L138.exe will only take a UBL plus 1 image.   I'm unsure how to get the 2nd  or 3rd imageimage flashed into memory.  I've tried using sfh_OMAP-L138.exe to flash 1 file to a seperate block (16 below both with and without a UBL) before but it never worked.

sfh_OMAP-L138.exe -flash -p COM5 -targetType AM1808 -APPLoadAddr 0xc0000000 -APPStartAddr c00117a4 -appFlashBlock 16 UBL_SPI_MEM.bin TestAccel.binary

and

sfh_OMAP-L138.exe -flash_noubl -p COM5 -targetType AM1808 -APPLoadAddr 0xc0000000 -APPStartAddr c00117a4 -appFlashBlock 16 TestAccel.binary

If I get that to work, do you know what kind of header, if any it puts in front of the binary to tell you about it?

Zachary Hilbun said:

It complains about 2 vector areas .vecs and .vectorTable.  Do they both need to be copied to their respecitve addresses ( 0ffff0000h and 0ffff0040h) or just one?

If you add a single ROMS definition that encompasses both the .vecs and .vectorTable addresses then you will end up with a single file for that area of memory.  You'll need to look in the map file to see how large .vectorTable is.

Zachary Hilbun said:

f I wind up with multiple files, how do people go about flashing that many files? 

One hack would be just to concatenate the two files into a single file:

http://support.microsoft.com/kb/71161

Your UBL code would just have to "know" that the first 192KB goes to one place and the remaining amount goes to another.

Zachary Hilbun said:

If I get that to work, do you know what kind of header, if any it puts in front of the binary to tell you about it?

There is no header for image mode.  You're just getting the raw contents.  So right now I expect you're getting a 192KB image based on your ROMS definition and that corresponds byte for byte to what you should copy into memory.

Zachary,

I think I have an alternate solution for you that will be easier to use and more flexible with regard to supporting applications with memory in multiple places of the memory map.  In particular download the latest version of Starterware from here:

http://www.ti.com/tool/starterware-sitara

There's an example in there called "bootloader" that contains parser code for a format we call RPRC.  Inside the tools/out2rprc folder is a utility for taking your *.out file and generating the RPRC binary which you would burn to flash.  So the advantage here is that it will "pack" multiple memory ranges into a single file and put the appropriate header information in place for the bootloader to parse and load the image.  The corresponding rprc parser code for can be found in bootloader/src/bl_rpc.c.

This is the recommended way to create a secondary bootloader as it works around all the difficult issues you're currently encountering.  It should also result in a much smaller binary since it will be "packed" rather than an image of the entire internal RAM!

FYI, I likely will not be able to participate any more on this thread for at least a week because I'll be on vacation.  My recommendation here would be to switch gears to use the Starterware bootloader (though you could still use the serial flash utility to burn it into flash).  Furthermore, since I'll be gone and this thread has gotten quite lengthy it would likely be best to start a "fresh" thread over in the Starterware Forum if you continue to have issues.

Brad

I've got one other nugget of information for you...  The sfh program actually adds a header onto whatever it's writing into flash.  So if your current setup is parsing a header it's because sfh put it there, not the hex conversion utility.  Furthermore, the RPRC parser is also looking for that same info so it would be required to use sfh in conjunction with the RPRC tools/code in order to get that header in place.

Thanks, I already knew that sfh was the app that placed the header into flash.