MLO file for AM35x

Matt,

Have you looked at the hex utility?  It might be of use.  It is used to take the .out file and create a flash image in a couple of different formats.  Between that and the map file you may have what you need.  Both can be generated as part of the CCS build.  To generate the hex file go to the build properties, click on the build steps tab and then at the bottom there is a drop down list of pre-defined build steps.  Select the one to create a flash image in TI-TXT format.  You will need to adjust the command.  I changed mine to look like this:

"${CG_TOOL_ROOT}/bin/hex${CG_TOOL_SUFFIX}.exe" --ti_txt "${BuildArtifactFileName}" -o "${BuildArtifactFileBaseName}.txt" -order M -romwidth 32

I had changed the -order and -romwidth values. I just changed them to something to get the file to be generated, you will want to check the docs to see what the correct settings are for you.

After a build the map and txt (hex) files should be in your project configuration folder (\Debug).

Regards,

John

HEX FILE

@0004

38 07 00 00 20 A0 00 00 80 F2 00 00 40 96 00 00 

00 00 00 00 

@next address

data

MAP FILE

SECTION ALLOCATION MAP

 output                                  attributes/

section   page    origin      length       input sections

--------  ----  ----------  ----------   ----------------

.pinit     0    00000004    00000014     

                  00000004    00000004     main.obj (.pinit)

                  00000008    00000004     rts64plus.lib : iostream.obj (.pinit)

                  0000000c    00000004                   : locale0.obj (.pinit)

                  00000010    00000004                   : wiostrea.obj (.pinit)

                  00000014    00000004     --HOLE-- [fill = 0]

Thanks for your reply.

The hex470 tool doesn't work completely.

a) using a text file format isn't going to work, because the MLO file is a binary image.

b) in binary mode (-b, undocumented (but why???)) it leaves holes in the .data and .const sections which alter the load addresses and will cause incorrect operation of the unit.

c) it provides no way to store the two values (length and load address) from what I read in the documentation.

Matt

Matt,

I mis-spoke about the .retain assembler directive. Sorry about the confusion.

The wiki page that talks about it refers to C6000 CGT v7.2 which supports it. The ARM CGT v4.6.x does not seem to support the .retain assembler directive but does support the --retain linker option, so please use this method for now. The next production release of the ARM CGT scheduled for later this month will support the .retain directive also.

Thanks for clearing that up, but --retain=.mlo doesn't work, either.

The .obj file for mmcload:

Disassembly of mmcload.obj:

TEXT Section .text, 0x8 bytes at 0x0
000000:              mmcload:
000000:               .arm
000000: 04F01FE5         LDR             PC, lc_int00 [0x4]
000004:              $d:
000004:              lc_int00:
000004: 00000000        .word            0x0000

DATA Section .mlo, 0x8 bytes at 0x0
000000:              $d:
000000:              .mlo:
000000:              mlolen:
000000: 00000000         .word 0x00000000
000004:              loadaddr:
000004: 40200000         .word 0x40200000

DATA Section .const, 0x4 bytes at 0x0
000000:              matt:
000000:              $d:
000000:              .const:
000000: 000004d2         .word 0x000004d2

The output from the linker:

"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/TMS470 Code Generation Tools 4.6.4/bin/cl470" -mv7A8 -g --gcc --diag_warning=225 -me --enum_type=packed --abi=eabi --code_state=32 -k --asm_listing -z -m"tasngbl.map" --stack_size=0x800 --heap_size=0x800 --verbose_diagnostics --display_error_number --diag_suppress=10063 --issue_remarks --warn_sections -i"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/TMS470 Code Generation Tools 4.6.4/lib" -i"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/TMS470 Code Generation Tools 4.6.4/include" --reread_libs --entry_point=mmcload --retain=.mlo --rom_model --fill_value=0xff --zero_init=off -o "tasngbl.out"  "./syscall.obj" "./mmcload.obj" "./main.obj" "./ff.obj" "./diskio.obj" -l"C:\Documents and Settings\mgessner\Desktop\workspace\am35xxlib\Debug\am35xxlib.lib" -l"rtsv7A8_A_le_n_eabi.lib" "../tasngbl.cmd"
<Linking>
"../tasngbl.cmd", line 8: warning #10068-D: no matching section
   .mlo: { mmcload.obj(.mlo) } > shared_ram

(line 8 contains ".mlo: { mmcload.obj(.mlo) } > shared_ram")

Am I supposed to use a UNION to do what I want?  Essentially, I want the linker to output the two words at the beginning in the ELF file, but I want the program to be LINKED as though the base address was 0x40200000.

You know what?  We're going to lie to the linker, and tell it that the start is at 0x401FFFF8, and put the two words at the start of the file that way.

Now I just have to figure out how to get the linker command file to store the length.

Matt

MATT GESSNER said:

Thanks for clearing that up, but --retain=.mlo doesn't work, either.

The option needs a file specifier then the section:

--retain=mmcload.obj(.mlo)

or if you want to retain .mlo from all files:

--retain=*(.mlo)