RTOS/OMAP-L138: Problem with vectoring directly to a 'ROM Mode' binary image.

Hi Keith,

Do you see this issue when loading non-SYSBIOS applications linked with 'ROM initialization' using your bootloader?  __TI_auto_init() is technically not a part of SYSBIOS. It is a function linked in by the linker to initialize global variables. Refer to section 6.10 'System Initialization' in the ARM Optimizing C/C++ Compiler User's Guide for more details: http://downloads.ti.com/docs/esd/SPNU151/index.html#SPNU151N_HTML/run-time-environment.html?Highlight=rom_model

The compiler forum should also be able to help if you have specific questions regarding how system initialization is performed.

Best regards,

Vincent

Hi Vincent,

Thanks in advance for your help. Should I move this to a different forum?

Yes, my Boot Loader actually looks at a discrete to determine which application to toad.  There are 2 possible applications, one is a SYSBIOS application, and the other is a vanilla C run-time application.  The C run-time application loads and executes every time, the SYSBIOS one does not.

When I look at my map files, the __TI_auto_init appears to come from different libraries for the 2 applications though:

From my SYSBIOS application map file: 

c3000000 00000060 boot.ae9 : boot.oe9 (.text)
c3000000 000000d7 ARM_Ground_Program_pe9.oe9 (xdc.meta)
c3000060 00000008 rtsv5_A_le_eabi.lib : args_main.obj (.tramp._args_main.1)
c3000068 00000008 auto_init.ae9 : auto_init.oe9 (.tramp.__TI_auto_init.1)
c3000070 00000008 rtsv5_A_le_eabi.lib : exit.obj (.tramp.exit.1)

From my C run-time application map file: 

.init 0 c0000000 00000060
c0000000 00000048 rtsv5_A_le_eabi.lib : boot.obj (.text)
c0000048 00000008 : args_main.obj (.tramp._args_main.1)
c0000050 00000008 : auto_init.obj (.tramp.__TI_auto_init.1)
c0000058 00000008 : exit.obj (.tramp.exit.1)

In my SYSBIOS linker command file (in addition to the auto-generated one by the RTOS), I do this to force my entry point to a certain address:

{

.init: { boot*(.text)} > 0xC3000000

}

In my C run-time linker command file (the only one in this project), I do this to force my entry point to a certain address:

.init : {rtsv5_A_le_eabi.lib<boot.obj> (.text)} > 0xC3000000

Keith

Hi Keith,

Is there any difference between what your bootloader does for a SYSBIOS application vs a non-SYSBIOS one? If so, I'd suspect an issue with the code that is specifically handling the SYSBIOS application. Not sure what you meant by "my Boot Loader actually looks at a discrete to determine which application to toad". (Btw, the map file for the C run-time application seems to indicate you have loaded it to a different address than what is shown in the linker command file - maybe that is just a typo.)

Meanwhile, here are some links I found that may be of help:
e2e.ti.com/.../303974
e2e.ti.com/.../106611
processors.wiki.ti.com/.../Boot_Images_for_OMAP-L138
e2e.ti.com/.../1839020

Could you check if this information helps you resolve your issue? The last thread in particular seems to indicate success when bootloading a SYSBIOS program onto the ARM.

Best regards,
Vincent

Hi Vincent,

Thanks a ton for your help!

I have solved my issue.  It ended up being an issue with how I compressed and stored the binary image that the tiobj2bin.bat tool created for me.

Since my program is located at 0xC3000000 and my vectors are stored at 0xFFFFFFFF, the single binary image that tiobj2bin.bat created for these ended being almost 1 GB in size.

I developed a tool to use run-length encoding to compress the image down, and also split the program and vectors into 2 smaller images that I store in NOR Flash.

To do this, I used information in the map file to find the end of the program.  This is what led to my problem.

I utilized the 'used' value in the 'MEMORY CONFIGURATION' to find the end.
Using my map snippet below this yields 0xC3000000 + 0x00434117 = 0xC3434117

It turns out, this is not truly accurate.  If you look a little farther in the map file in 'SEGMENT ALLOCATION MAP' it says that the .cinit section (which is the last section physically in the program code)
starts at 0xC34330D8 and is 0x1048 in length.........0xC34330D8 + 0x1048 = 0xC3434120

The 'MEMORY CONFIGURATION' is always 9 short of how big the .cinit section actually is.
Because of this, I inadvertently cut off the end of the .cinit section, which causes Auto_Init() to go off into the weeds.

The reason why it would work sometimes is that I also embedded a 32-bit CRC directly after the program code.  In some instances this CRC value would equate to a semi-valid .cinit entry, and things would at least limp along.

I updated my binary compressing tool to account for this discrepancy and it is now working 100% of the time.

I also added a few 0 value words proceeding the table because I saw in some other posts that this may be necessary to mark the end of the .cinit table itself (aka let the Auto_Init() function know to stop initializing constants)

Keith

Map file snippet

...
...

name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
L3_CBA_RAM 80000000 00020000 00000000 00020000 RW X
DDR c3000000 03000000 00434117 02bcbee9 RW X
IRAM ffff0000 00002000 00000368 00001c98 RW X

SEGMENT ALLOCATION MAP

run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------
c3000000 c3000000 00000078 00000078 r-x
c3000000 c3000000 00000078 00000078 r-x .init
c3000078 c3000078 003816da 00000000 rw-
c3000078 c3000078 003816da 00000000 rw- .bss
c3381754 c3381754 0000002c 0000002c r-x
c3381754 c3381754 0000002c 0000002c r-x .text.1
c3381780 c3381780 00058cc0 00000000 rw-
c3381780 c3381780 00058cc0 00000000 rw- .far
c33da440 c33da440 0003fffc 0003fffc r-x
c33da440 c33da440 0003fffc 0003fffc r-x .text.2
c341a43c c341a43c 00010000 00000000 rw-
c341a43c c341a43c 00010000 00000000 rw- .stack
c342a43c c342a43c 00001bc4 00001bc4 r--
c342a43c c342a43c 00001bc4 00001bc4 r-- .const.1
c342c000 c342c000 00004000 00000000 rw-
c342c000 c342c000 00004000 00000000 rw- ti.sysbios.family.arm.arm9.mmuTableSection
c3430000 c3430000 000011f9 000011f9 r--
c3430000 c3430000 000011f9 000011f9 r-- .const.2
c34311fc c34311fc 00001ed8 00000000 rw-
c34311fc c34311fc 00001ed8 00000000 rw- .data
c34330d8 c34330d8 00001048 00001048 r--
c34330d8 c34330d8 00001048 00001048 r-- .cinit
ffff0000 ffff0000 00000368 00000368 r-x
ffff0000 ffff0000 00000040 00000040 r-- .vecs
ffff0040 ffff0040 00000328 00000328 r-x .vectorTable

...
...

There was a suggested answer and since there has been no active on this thread for more than a week, the suggested answer was marked as verify. Please feel free to select the "Reject Answer" button and reply with more details.