maptool.py / ofd6x error: "Unassigned segment found"

Hello James,

 While using the MAP tool all the segments in an elf file have to be explicitly placed into a memory partition in the deployment configuration file. The above error means that the ELF segment numbered 0,2,4,5,6... have not been identified and placed into a memory partition in the deployment configuration file.

To list all the segments in an elf file you can use the "ofd6x" tool from CGT. For example "ofd6x -v app_local > objdump.txt" will do a verbose dump of the elf file. It will list the "Program Segment Table" towards the begining of the dump. For all the segment numbers for which the map tool gave an error, you will have to place those segments into a memory partition (e.g ddr-code, ddr-data) in the deployment config file.

A segment is identified in the deployment configuration file by a containing section name.

Best regards

Sandeep

Thanks. I tried your suggestion by explicitly mapping a couple of the sections and it does remove the errors.

I am actually generating the deployment file before calling maptool.  My intent was to press a button and have it build all the execs, then call maptool to glue them together, placing the result on the FTP server.  Is there any easy (but also sensible) way to cover all cases?  Would I have to extend my deployment file generation to do the lookup in the objdump you showed me how to do manually, or is there a wildcard I can use to map all unmapped sections to one memory partition or the other?

Can you point me to any documentation on what to map to ddr-code and what to map to ddr-data?  I assume there is good reason to maintain this separation, or is it a by-product of the example and I could just have one partition?

Hello James,

 With the current MAP tool design the user has to explicitly do "segment -to- memory partition" mapping for all segments. There is no wildcard mapping feature.

There is no rule about the number of partitions you can have. The partitions "ddr-code", "ddr-data" is a very simplistic example. The user has to decide the number/attributes of partition and the segment placement based on the application characteristic. For example you may want performance critical portion of the application to be placed into internal memory. I'm not sure if there is any document providing guidance on this, but the image processing is a good example. You can have a look at the deployment configuration of the image processing demo as an initial template.

Best Regards

Sandeep

After mapping everything I now get this error during prelink.  Can you explain?  (Edit: sentence removed that didn't make sense or help.)  Because the "is not dynamic" implies to me I linked my executable in an unexpected way I will paste that link line as well at the bottom.  Thanks again.

c:\gedev\tibsp\control>"C:\Program Files\Texas Instruments\ccsv5\tools\compiler\
c6000\bin\prelink6x" c:\users\jim\appdata\local\temp\tmpda_yuo\prelink.cmd
error: input object file,
   'c:\users\jim\appdata\local\temp\tmpda_yuo\app_local', is not dynamic
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 1: error: illegal
   input character: '0x7f'
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 1: error: invalid
   option: -î☺Z
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 2: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 3: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 3: error: invalid
   option: -î☺Z*►☻zƒ
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 6: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 9: error: invalid
   option: -►☻X
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 11: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 12: error: invalid
   option: -î☺
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 13: error: illegal
   input character: '0xffffffa8'
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 13: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 14: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 15: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 16: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 18: error: illegal
   input character: '0x1d'
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 18: error: invalid
   option: -┤íüî☻h
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 19: error: invalid
   option: -↑♥z┐É☻z╧¶
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 24: error: invalid
   option: -►m*
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 24: error: invalid
   option: -►m*
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 24: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 24: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 26: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 27: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 36: error: illegal
   input character: '0x16'
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 39: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 40: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 40: error: invalid
   option: -|☻xƒ►
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 41: error: invalid
   option: -►☻┌
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 43: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 45: error: invalid
   option: -►☻∙Åⁿ☺(
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 46: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 50: error: invalid
   option: -►☻┌
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 55: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 56: error: invalid
   option: -►☻∙Åⁿ☺(
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 56: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 57: error: invalid
   option: -►☻~/
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 58: error: illegal
   input character: '0xffffffd4'
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 62: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 63: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 65: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 66: error: illegal
   input character: '0xffffffd0'
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 67: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 68: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 68: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 91: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 97: error: invalid
   option: -☻yp╨☺h/‼☻xÇî☺░╟ì☺ÿ▀↑☻x└î☻x┐ÿ☺°Åî☺*+∟
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 99: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 99: error: invalid
   option: -≥
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 99: error: invalid
   option: -►☻°hÿ☺y⌂É☺·╕↑☻g·ëò
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 101: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 103: error: invalid
   option: -¶ú!↑3C Çé╓╧o╚{Ŷ u☻°
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 103: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 104: error: invalid
   option: -ö☺ßg┤☻[Ç»☻µó<☻ßgÉ☺x¬
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 108: error: invalid
   option: -►☻∙»►
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 109: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 109: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 109: error: invalid
   option: -►┼╪☼,┬!aA
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 110: error: invalid
   option: -►2X
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 112: error: invalid
   option: -î☺
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 113: error: invalid
   option: -ö☻±+î☻∙k╣☼(
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 113: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 113: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 117: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 126: error: invalid
   option: -►┬
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 126: error: invalid
   option: -►┬
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 127: error: invalid
   option: -ö☻n
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 127: warning:
   unterminated quote
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 128: error: illegal
   input character: '0x3'
"c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 128: warning:
   unterminated quote
fatal error: cannot find file:  z
ERROR: Prelinker run pass-1 failed

Here is the link line:

C:/Progra~1/TexasI~2/ccsv5/tools/compiler/c6000/bin/cl6x -mv6600 -m"emb.map" emb.obj -diag_warning=225 --abi=eabi -z --reread_libs --rom_model --warn_sections "c:/gedev/tibsp/hello/gedae.cmd" --symbol_map xdc_runtime_Timestamp_get32__E=xdc_runtime_Timestamp_get32__F --symbol_map ti_sysbios_hal_Timer_getFreq__E=ti_sysbios_hal_Timer_getFreq__F -ic:\gedev\system/nt/ti_c6678/lib -l"libembedded.a" -l"libent_target_bsp.a" -l"libembedded.a" -ic:\gedev\system/nt/ent/lib  -i"C:/Progra~1/TexasI~2/ccsv5/tools/compiler/c6000/lib" -i"C:/Progra~1/TexasI~2/ccsv5/tools/compiler/c6000/include" -l"libc.a" -l"C:/Progra~1/TexasI~2/pdk_C6678_1_0_0_12/packages/ti/platform/evmc6678l/platform_lib/lib/release/ti.platform.evm6678l.ae66" -l"C:/Progra~1/TexasI~2/xdctools_3_22_01_21/packages/ti/targets/rts6000/lib/ti.targets.rts6000.ae66" -l"libent_target_bsp.a" -l"libemb_fncs.a" -o "emb.out"

Hello James,

The executable needs to be built as relocatable. You will need to pass the options " --dynamic --relocatable" to the linker.

Best regards

Sandeep

My current example with maptool does not seem to work.  I have made all the adjustments (as above) to get it to pass through maptool.py but the resulting app.out file does not startup correctly via an FTP boot.  My test simply flashes LEDs and writes to the serial output after EVM_init, and then loads BIOS and goes into the idle-loop.  (It loads a lot of other code for sockets, etc. that I will need after I get past this test.)  However running the maptool output, the LEDs never flash and the terminal output never shows up.  I see the FTP download, but then the EVM does nothing that I can tell. 

My FTP boot works with examples like the Image Processing "mcip-c6678-le.bin" so I think that is setup correctly and the problem is isolated to what I did to maptool.  I can also load the individual executables manually in CCS and get the flashing LEDs, terminal output, and suspend the task in the BIOS idle-loop.  It appears the executables are ok, but not the maptool.py output.

Is there any way to debug this? I have attached my changes to the deployment.json file.  I get several "Warning: Incompatible permissions for partition ddr-code" - do I need to worry about these?

{
"deviceName" : "C6678",
"partitions" : [
       {
               "name"                  : "ddr-code",
               "vaddr"                 : "0x80000000",
               "paddr"                 : [ "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000"] ,
               "size"                  : "0x4000000",
               "secNamePat"    : ["^.text", "const", "switch", "rodata", "cinit" ],
               "cores"                 : [0,1,2,3,4,5,6,7],
               "permissions"   : ["SR", "SX"],
               "cacheEnable"   : true,
               "prefetch"      : true,
               "priority"              : 0,
               "shared"                : true,
               "loadPartition" : true
       },
       {
               "name"                  : "ddr-data",
               "vaddr"                 : "0xD0000000",
               "paddr"                 : [ "0x806000000", "0x807000000", "0x808000000", "0x809000000", "0x80A000000", "0x80B000000", "0x80C000000", "0x80D000000" ],
               "size"                  : "0x1000000",
               "secNamePat"    : ["stack", "^.far$", "args", "neardata", "fardata", "far.1", "far.2", "far.3", "far.4", "far:NDK_PACKETMEM", "systemHeap", "qmss", "platform_lib", "bss", "cppi", "nimu_eth_ll2" ],
               "cores"                 : [0,1,2,3,4,5,6,7],
               "permissions"   : ["SR", "SW"],
               "cacheEnable"   : true,
               "prefetch"      : true,
               "priority"              : 0,
               "shared"                : false
       }
],
"applications" : [
       {
               "name"                   : "app_local",
               "fileName"       : ".\\emb.out",
               "libPath"        : ".",
               "allowedCores"   : [0,1,2,3,4,5,6,7]
       }
],
"appDeployment" : [
        "app_local"
       ,
        "app_local"
       ,
        "app_local"
       ,
        "app_local"
       ,
        "app_local"
       ,
        "app_local"
       ,
        "app_local"
       ,
        "app_local"
]
}

Hello James,

 I can try to debug this. Can you please send me the following:

1.  zip of the "tmp" directory

2. the original application out file "emb.out"

Regards

Sandeep

Here are the files.  Thanks a lot!

0827.emb.zip

6646.tmp.zip

Hello James,

 I think I see some issue when the original emb.out is prelinked to form app_local. The stack pointer in app_local is not getting initialized properly, I'm still debugging this issue and will update you as soon as I have more info.

Regards

Sandeep

Hi James,

 Sorry for the delay in response. I have attached the modified deployment file which tries to match the original emb.out.

I had a few questions on the procedure you are using:

1. Are you using the Code generation tools version 7.2.4? I found that the application emb.out was linked with version 7.2.1. Please note that MAD utils may not work with cgt version < 7.2.4.

2. Do you intend to load the same application (app_local) on all the 8 cores. If so have you ensured that the application is multicore safe? Since your application is based on NDK example, as far as I know NDK cannot be run on all cores.

Please try the modified deployment file with CGT 7.2.4 and let me know the results.

Regards

Sandeep

{
"deviceName" : "C6678",
"partitions" : [
       {
               "name"          : "ddr-code",
               "vaddr"         : "0x80000000",
               "paddr"         : [ "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000"] ,
               "size"          : "0x4000000",
               "secNamePat"    : ["^.text", "const", "switch"],
               "cores"         : [0,1,2,3,4,5,6,7],
			   "permissions"	: ["UR", "UW", "UX", "SR", "SW", "SX"],
               "cacheEnable"   : true,
               "prefetch"      : true,
               "priority"      : 0,
               "shared"        : true,
               "loadPartition" : true
       },
       {
               "name"          : "ddr-data",
               "vaddr"         : "0xD0000000",
               "paddr"         : [ "0x806000000", "0x807000000", "0x808000000", "0x809000000", "0x80A000000", "0x80B000000", "0x80C000000", "0x80D000000" ],
               "size"          : "0x1000000",
               "secNamePat"    : [ "^.far", "bss", "neardata", "rodata", "args", "cio", "fardata", "systemHeap", "qmss", "platform_lib"],
               "cores"         : [0,1,2,3,4,5,6,7],
			   "permissions"	: ["UR", "UW", "SR", "SW"],
               "cacheEnable"   : true,
               "prefetch"      : true,
               "priority"      : 0,
               "shared"        : false
       },
		{
			"name"		: "L2SRAM",
			"vaddr"		: "0x800000",
			"paddr"		: [ "0x800000", "0x800000", "0x800000", "0x800000", "0x800000", "0x800000", "0x800000", "0x800000" ],
			"size"		: "0x100000",
			"secNamePat"  	: ["resmgr_pa", "stack", "nimu_eth_ll2"],
			"cores"		: [0,1,2,3,4,5,6,7],
			"permissions"	: ["UR", "UW", "SR", "SW"],
			"cacheEnable"	: false,
			"prefetch"      : false,
			"priority"	: 0,
			"shared"	: false
		}
],
"applications" : [
       {
               "name"           : "app_local",
               "fileName"       : ".\\emb.out",
               "libPath"        : ".",
               "allowedCores"   : [0,1,2,3,4,5,6,7]
       }
],
"appDeployment" : [
        "app_local",
        "" ,
        "" ,
        "" ,
        "" ,
        "" ,
        "" ,
        ""
]
}

Thanks Sandeep.  I appreciate the time invested and no problem on the delay.  I will try it out ASAP, but that might not be for a few days.

Yes, I was trying to put NDK on every core and connect on different port numbers to the Window host.  I wasn't aware this wasn't possible.  If it's not I can do a store and forward approach instead and only connect to a master core.

Hi Sandeep and all

Sorry for the long delay.  I finally had a chance to try this week, and unfortunately it hasn't seemed to make a difference.  The EVM is still nonresponsive with the maptool output for my NDK-based code.  The FTP server shows the file is downloaded, but I get no indication it has actually started up (it should light LEDs and print to terminal).

I have upgraded everything to 7.2.4 and rebuilt.  I used your deployment file directly.  

I do get LED and terminal activity when I load the executable through CCS.

Here's a zip with some files it creates

emb.out - executable for 1 core, what runs in CCS

app.out - output of maptool (does it make sense that app.out is much smaller than emb.out?)

tmp directory

2055.CompilerOutput.zip

Hi James,

 I still see that the executable emb.out has been linked with linker version 7.2.1. Can you please check that emb.out is really getting built with version 7.2.4.

Regards

Sandeep

You're right, it was still linking with 7.2.0 even though the compilation was 7.2.4.  Fixing that doesn't fix my main problem though.  Unless I still didn't do it right.

3073.emb.out.zip

1184.app.zip

can you please send me the zip of the "tmp" directory too.

Regards

Sandeep

Here it is, thanks

3582.tmp2.zip

I have very similar issues. My configuration is
   Host: Windows 7 machine
   Target: C6678 (EVM, and soon a custom board)
   CCS version: 5.0.3.00028    (according to compiler README this suite is version 7.2.1)
   MCSDK: 2.00.03.15
Is the compiler suite version (7.2.1) the problem? The suggested linker options "--dynamic --relocatable" seems not to be supported. In that case, is it possible to update the compiler suite separately without breaking the rest of the development environment?
I cannot update the CCS version to the latest (5.1) because in the latest version lots of features and packages for multicore seems broken or missing (there are other postings about this in this forum).
What is your suggestion to get around this problem?
Regards, M

Marty,

The BIOS MCSDK download page (http://software-dl.ti.com/sdoemb/sdoemb_public_sw/bios_mcsdk/latest/index_FDS.html) has a link to the recommended compiler (Codegen Tools) version. The compiler version supported in this release is 7.2.4. Please update the toolchain, the build should work fine.

Regards

Sajesh

Hi Sandeep

Glad my example could help improve maptool.  Your workaround gets me over this problem.

Thanks for your help

Jim

Sandeep Nair said:

2. Do you intend to load the same application (app_local) on all the 8 cores. If so have you ensured that the application is multicore safe? Since your application is based on NDK example, as far as I know NDK cannot be run on all cores.

Hi Sandeep

Is there anyway I can verify NDK is not "multicore safe"?  The documentation states it is "thread safe" - is this the same thing as "multicore safe" or different in TI parlance?

Good news is I now have an example based on NDK booted from FTP running on 1 core with socket comm to and from.  I am now trying to run something (anything) on a 2nd core and running into problems.  (Ideally I could run sockets on 8 cores using a FTP/maptool boot, but I will be happy if I can FTP/maptool boot with sockets on core 0 and other code on 1-7 using shared memory IPC between the TI cores.)

The maptool output of my 2 core test doesn't start up.  The behavior is similar to my initial tests on a 1 core mapping:  My example should flash the LED as it boots and this doesn't happen.  I am attempting to do a trivial test where I map the same emb.out executable to 2 cores. There is NDK code in the executable but I have prevented it from entering the NC_SystemOpen or NC_NetStart routines to hopefully avoid that issue until I can see output again

if you think it makes sense for you to debug it, here is a zip with the deployment, tmp, app.out and emb.out files.

2273.test2core.zip

Thanks

Jim

Hi Jim,

 If I understand the problem correctly, when you load emb.out executable through CCS on core 0 & core 1, the executables would flash the LED, both from core 0 & core 1. But when you load it through MAD loader, the LED's don't flash.

I will try to check this sometime early next week. If it is possible for you to wait, the next BIOS-MCSDK release 2.0.5(due end of next week) will have some of the bug fixes which were uncovered by your use case. The new release will also have a mode where you can use MAP tool/MAD loader as a simple multicore loader.

Regards

Sandeep

Yes that is correct, it works in CCS. 

Additionally using Madloader, I tested "emb.out" on core 0 and a do-nothing while (1) loop on core 1 and the LEDs don't flash.

It would be great to verify whether or not 2.0.5 fixes this too.

Thanks.

Jim

Sorry to be a pest.  Did you have a chance to look at it, and if not can you give me an estimate when you will?  Thanks

Hi James,

 I just ran the maptool on my PC with the emb.out & deployment config given by you. When I run the app.out produced by this run, it flashed the LED. I'm suspected it has something to do with the MAD loader binaries which you built. By any chance did you update the madloader binaries between your successful/non-successful run. I have attached the app.out and the mad-loader binaries I used.

Regards

Sandeep 0020.james_debug.zip

Hi Sandeep

Which maptool version are you using?  Are you using the new version I don't have access to?  Or are you using only things from an already-released MCSDK?

It doesn't work if I build it.  The app.out you built works (the LED flashes after the image is downloaded from FTP) but not the one I build. 

I am not sure how the mad-loader binaries integrate into the maptool/FTP process.  I see the path to the tools in the configuration file but don't see where they are called in the python scripts.  In case it makes a difference, all I am doing is running maptool, then rebooting the card to reload via FTP.  Your binaries were different than mine but using yours didn't make a difference on my end:  1 core still works, 2 cores doesn't work.

If you are using the new maptool this is probably good news and once the new maptool is released (2.0.5?) hopefully it will work for me.  I just want to make sure I understand why it didn't work for me.

Thanks again for looking

Jim

Hi Jim,

 I was using the older released version of MAP tool. When I loaded your app.out, I found that the MAD loader was stuck in a loop waiting for core-1 to come out of reset. That is why I was suspecting that the MAD loader. The MAD loader executables are specified in the MAP tool config file (maptoolCfg.json) with the following lines:

    "malApp"        : "./mad-loader/mal_app.exe",
    "nmlLoader"        : "./mad-loader/nml.exe"

Can you please modify your config file to pick up the MAD loader executables I sent you, and let me know the results.

Regards

Sandeep

Sandeep,

I am following this thread closely as I continue to have some issues with the map/mad tool.

After following your recommendation to build the .out files with compiler version 7.2.4 instead of 7.2.1, I usually :-) manage to build the mad/filesystem image. However, I keep getting the following warning from the map tool: "Warning: Incompatible permissions for partition *", where * is ddr-code, ddr-data, and L2SRAM, respectively. Don't know if I should worry about that?

What's worse is my main problem: I fail to verify that the mad image is working. We are still waiting for our custom-built board to arrive. Meanwhile, I want to ensure that the whole MAD-generation process is working, and the only option I can think of is to use the debugger on our EVM, loading the mad filesystem image into DDR3 and jumping into the entry point at offset 0x1040. I can't think of a reason I should not be able to debug the reboot of the cores in this way?

In my test, I use a small application called "blink" that repeatedly blinks the LEDs on the EVM, and I have verified that the "blink" app itself is working. I have built a MAD image that should load the blink app onto core 0, 1, and 2. When I test (with the debugger, connected to core 0) the mad image on the EVM, the debugger fails with some "...CPU stall..." blablabla when I execute line 401 in file mal_lib_loader.c:

Line 400:    reg = (unsigned int*)MDCTL_ADDR(mod_id);
Line 401:    *reg = (*reg & ~ MDCTL_NEXT_STATE_MASK) | MDCTL_NEXT_STATE_EN;
Line 402:    *reg = (*reg & ~ MDCTL_LRSTZ_MASK) | MDCTL_LRSTZ_MASK;

(also, line 402 looks like a bug to me, the bit will not get toggled, which I assume is the intention, if it was already '1'.
   This might be safer option: *reg = (*reg &= ~MDCTL_NEXT_STATE_MASK) | MDCTL_NEXT_STATE_EN; )

Anyway, after executing line 401, the debugger can't connect to any of the cores. Maybe this is expected? But if any of the cores REALLY did a proper boot then I would have expected to see some LEDs blinking away...

Can you please advice whether my test makes sense to you?

Hi Sandeep,

This is what I tried last week.  More precisely, I overwrote the files the maptoolCfg was pointing to and reran maptool.  I tried it again today to make sure and the lights don't flash.

Thanks

Jim

Sandeep Nair said:

Hi Jim,

 I was using the older released version of MAP tool. When I loaded your app.out, I found that the MAD loader was stuck in a loop waiting for core-1 to come out of reset. That is why I was suspecting that the MAD loader. The MAD loader executables are specified in the MAP tool config file (maptoolCfg.json) with the following lines:

    "malApp"        : "./mad-loader/mal_app.exe",
    "nmlLoader"        : "./mad-loader/nml.exe"

Can you please modify your config file to pick up the MAD loader executables I sent you, and let me know the results.

Regards

Sandeep

 

Hi Marty,

 The warnings can be ignored as long as you are not very particular about enforcing strict access permissions. For example it would give a warning if the partition has "RW" permissions but the segment being placed there is read-only. But the tool will give an ERROR if it is the other way around.

Regarding the Debug of MAD loader your approach is right. 

For debugging the MAD boot (without IBL) you can simulate what IBL does using CCS with the following procedure.

1. Connect to core0. (Do all the required initializations (PLL/DDR3 etc.) using gel file). Ensure that you don’t connect to other cores, otherwise MAD loader won’t be able to boot the core.

2. Open a memory browser in CCS and load the memory at 0x80000000 with the ROMFS binary image created by MAP tool. The" type-size" should be 32bits while loading.

3. Set the PC to 0x80001040 (start of MAD loader), load the symbols for MAD loader application (mal_app.exe) and step through. 

Regarding the Bug, I will check that tomorrow and get back to you. Can I know which processor are you using - C6678 ?

Regards

Sandeep

Hi Jim,

Then the only variable I can think of is the MAP tool itself. I believe I used the released version of the tool. Can you please tell me the BIOS-MCDSK version you are using ?

Regards

Sandeep

Hi Sandeep

2.00.01.12 is my version number

1588.maptool.txt

Hi Sandeep, thx for the help so far.

The procedure you're describing is the one I am using exactly. And it is successful up until where Core0 is trying to boot Core1, at that point the debugger looses the connection with Core0 (and is not able to connect to any of the cores after that).

The DSP is a C6678 (on a C6678 EVM so far). And for the record, my versions are:

CCS: 5.0.0.00028 (with added upgrade of CGT to 7.2.4)
MCSDK: 2.00.03.15
PDK: 1.0.0.15

BR Marty

Hi Marty,

 This is an interesting issue. I suspect some malicious activity on Core-1 is causing this. One approach to debug this would be:

1. Stop the execution on core-0 at the entry to reset_run_core().

2. Connect to core-1 and set the PC to 0x80016400 (entry point of NML)

3. Load the symbols from nml.exe.dbg and step through.

Can you please send me the deployment configuration while you are using as well as the zip of the"tmp" directory produced by the MAP tool run.

Regards

Sandeep

Hi Jim,

 I used the tool from version 2.0.3.x(+ some custom code for debug purpose) , but I believe there is no significant difference in the code from version 2.0.1.x. I think you should be good with the tools coming out in version 2.0.5. If I'm able to manage some time before the 2.0.5 release, I will give a try to your example with the MAP tool from version 2.0.1.

Regards

Sandeep

Hi Marty,

 The MAP tool prelinks the original executable to new address as specified in the deployment configuration file. Since you had the "text" segment to be moved to DDR, the entry point (_c_int00) got moved to DDR. But that configuration should also work.

Since you want both code and data to be placed into L2 RAM of each, I have attached the modified deployment configuration file, which does that. I ran the output produced by the modified deployment configuration and got the following output on the serial terminal. SO I assume it is working.

EVM6678 log initialized....
frequency = 1000 MHz
Cache settings:
   L1P cache is enabled
   L1D cache is enabled
   L2 cache is disabled
Blinking forever...

Regards

Sandeep

{
	"deviceName" : "C6678",
	
	"partitions" : [
		{
			"name"			: "ddr-code",
			"vaddr"			:  "0x80000000",
			"paddr"			: [ "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000", "0x800000000"] ,
			"size"			: "0x1000000",
			"secNamePat"  	: [],
			"cores"			: [0,1,2,3,4,5,6,7],
			"permissions"	: ["UR", "UW", "UX", "SR", "SW", "SX"],  
			"cacheEnable"	: true,
			"prefetch"		: true,
			"priority"		: 0,
			"shared" 		: true,
			"loadPartition" : true 
		},
		{
			"name"		: "L2SRAM",
			"vaddr"		: "0x800000",
			"paddr"		: [ "0x800000", "0x800000", "0x800000", "0x800000", "0x800000", "0x800000", "0x800000", "0x800000" ],
			"size"		: "0x80000",
			"secNamePat"	: ["text", "bss", "neardata", "const", "far"],
			"cores"		: [0,1,2,3,4,5,6,7],
			"permissions"	: ["UR", "UW", "UX", "SR", "SW", "SX"],
			"cacheEnable"	: false,
			"prefetch"      : false,
			"priority"	: 0,
			"shared"	: false
		}
	],
	
	"applications" : [
		{
			"name"		 : "hello",
			"fileName"       : ".\\ppy11boot.hello.mad.out",
			"libPath"        : "C:\\",
			"allowedCores"   : [0,1,2,3,4,5,6,7]
		}
	],
	
	"appDeployment" : [
		"hello",
		"hello",
		"hello",
		"",
		"",
		"",
		"",
		""
	]
}

Hi Sandeep, thanks so much for that! This was really helpful to me! :-)

I now realize I hadn't understood the re-linking part of the MAP tool. I was convinced that the purpose of the deployment file is only to control the memory map for the MAL and the NML apps only. I don't know Python so I didn't even try to understand the MAP code, and I didn't find any documentation that discusses the concepts thoroughly.

Can u confirm that I understand these things correctly now: 
* The MAP tool relocates the user app(s) only (in my example case, the "hello" app) according to the settings in the deployment file.
* This is the reason the user apps need to be built as "--relocatable".
* The MAP tool does not relocate the MAL and NML apps, their memory maps are defined in the conventional way, i.e. by their linker files at build-time, respectively.
* The reason why DDR3 external memory is used in the examples is that it is assumed that the user will want to place the user apps into internal memory.
* The term "blob" or "BBLOB" refers to the romfs filesystem image produced by the MAP tool.
* The MAL tool's main purpose is to parse the deployment information and the user apps elf files and create corresponding ARs (activation records, individual for each core).
* The concept with ARs (and their format) is a Texas Instrument invention and has nothing to do with elf/eabi.
* The ARs are written into reserved memory by MAL. When the NML of each core is "awakened", they will perform the instructions in their ARs, respectively.

One thing I'm still not sure of now is why the MAP tool seem to require that the applications also built as "--dynamic"? 

Thanx again, Marty

Hi Marty,

 Please see my reply inline.

** The MAP tool relocates the user app(s) only (in my example case, the "hello" app) according to the settings in the deployment file.
Sandeep> Yes
* This is the reason the user apps need to be built as "--relocatable".
Sandeep> Yes
* The MAP tool does not relocate the MAL and NML apps, their memory maps are defined in the conventional way, i.e. by their linker files at build-time, respectively.
Sandeep> Yes. They are built to be execute in place in the ROMFS image
* The reason why DDR3 external memory is used in the examples is that it is assumed that the user will want to place the user apps into internal memory.
Sandeep> One of the important use case for MAD tool is to enable sharing of common code among applications. That is why the example has a shared library. The shared code needs to be placed in shared memory, hence DDR3 was used in the example. All the ELF sections which you place in the load partition is mad execute in place. This is another important feature which the example was trying to show.
* The term "blob" or "BBLOB" refers to the romfs filesystem image produced by the MAP tool.
Sandeep> yes
* The MAL tool's main purpose is to parse the deployment information and the user apps elf files and create corresponding ARs (activation records, individual for each core).
Sandeep> Yes. It also does the virtual address assignment for the segments based on the placement information in deployement config and calls the prelinker to link it to the new address.
* The concept with ARs (and their format) is a Texas Instrument invention and has nothing to do with elf/eabi.
Sandeep> It is the set of actions which an ELF loader would take to load an application. In this case it is determined at the host, so that we can have a dumb loader on the target.
* The ARs are written into reserved memory by MAL. When the NML of each core is "awakened", they will perform the instructions in their ARs, respectively.
Sandeep> Yes

If your use case just asks for a multicore ELF loader and you want to avoid the prelink step, then you should have a look at the MAD tools which would be released with MCSDK 2.0.5. This version would include a "prelinker bypass" mode, where the MAD utils will just function as an ELF loader to load a static application on a given core.

Regards

Sandeep

Hi Sandeep

I noticed MCSDK 2.0.5 was released so I tried my examples with the new version.  I am still having trouble. I have 2 examples I am trying: running my app "emb.out" on 1 core and running "emb.out" on 2 cores.  With the previous MCSDK, the 1 core version worked after you gave me a workaround to get around issues with maptool.  With the current MCSDK, neither the 1 core or the 2 core versions work.  (Where "work" means the LEDs flash at the beginning of execution and text is printed to the serial port terminal for boot confirmation.)

Is there anything I need to be aware of in moving to 2.0.5 (anything else to upgrade, any changes to the deployment file syntax or requirements)? 

Is it possible you could look at my 2 core version and see if you see anything?  Or if you have any hints/instructions for debugging this myself? 

I have attached a ZIP with all my files in it. 

Thanks

Jim

6523.MCSDK205.zip

Hi Sandeep

I hope you had a good break. I didn't want this issue to get lost in the new year.  If you have any advice on what to do, please let me know.  It would be great if I could get past this startup issue as I think the rest of my work will be more straightforward.

Thanks

Jim

Hi Jim,

Sandeep is still on vacation. The new version of the MAD has the prelink_bypass option to just use it as elf loader. Did you tried the examples in the 2 0 5?

Thanks,

Arun.

Hi Jim,

 I'm back from vacation now. Did you get a chance to try your examples in the prelink-bypass mode as Arun suggested. This mode was specifically introduced to simplify deployment of example use cases like the one you have.

Regards

Sandeep

Hi Sandeep and Arun,

The prelink-bypass looks much friendlier.  Given I am generating these deployment configuration files, I really appreciate there are less options to mess up now.

However, I tried prelink-bypass with my executables and still not getting further.  I have attached a one core version.  emb.out works from CCS (flashes led, then prints to serial) but not from mad/FTP.

3730.prelink-bypass.zip

thanks for your help
Jim

Hi James,

 I tried the app.out file, which you had attached, on a C6678 EVM and I could see the following print on the serial console.

###    Starting    boot    sequence
QMSS    successfully    initialized
CPPI    successfully    initialized
PA    successfully    initialized
PASS    successfully    initialized
Ethernet    subsystem    successfully    initialized
Ethernet    eventId    :    48    and    vectId    (Interrupt)    :    7
Registration    of    the    EMAC    Successful,    waiting    for    link    up    ..
Hello    from    processor    0
Hello    from    processor    0
HOST    IS    192.168.1.180
failed    makeInetConnect:    connect    port    num    4000    error    6
accept
Network    Added:    If-1

So I assume that the MAD output image is OK. Most probably the IBL configuration on the EVM may be the issue. Can you ensure that the IBL configuration parameters are as follows on the board.

ibl.bootModes[2].ethBoot.blob.startAddress  = 0x9e000000;  /* Load start address */
ibl.bootModes[2].u.ethBoot.blob.sizeBytes     = 0x1000000;
ibl.bootModes[2].u.ethBoot.blob.branchAddress = 0x9e001040; /* Branch address after loading */

Regards

Sandeep

Hello Sandeep,

    I am now rebuiding the image processing demo image and have the same problem above, 

such as:

error: input object file, 'c:\users\eric\appdata\local\temp\tmpkopsq4\master',
is not dynamic

.......

I use mcsdk_2_01_02_06,  c6000_7.4.1 compiler,, and what do you mean by "You will need to pass the options " --dynamic --relocatable" to the linker."

Where can I set these parameters?

Thanks

Best regards,

Eric

Hello James,

      I have the same problem now, Can you explain how did you solve this problem:

c:\gedev\tibsp\control>"C:\Program Files\Texas Instruments\ccsv5\tools\compiler\ c6000\bin\prelink6x" c:\users\jim\appdata\local\temp\tmpda_yuo\prelink.cmd error: input object file,    'c:\users\jim\appdata\local\temp\tmpda_yuo\app_local', is not dynamic "c:\users\jim\appdata\local\temp\tmpda_yuo\app_local", line 1: error: illegal    input character: '0x7f'

......

ERROR: Prelinker run pass-1 failed

I have no idea of James said "The executable needs to be built as relocatable. You will need to pass the options " --dynamic --relocatable" to the linker."

what shall I do ?

Thank you very much!

Hi Eric,

You would pass --dynamic and --relocatable to cl6x when you link the executable.  Are you just trying to use the executables delivered in the MCSDK?

How are you invoking maptool?   You should check the prelink bypass option discussed on page 3 of this thread.   I don't think you have to make it dynamic or relocatable with prelink bypass.  Prelink bypass makes it a lot simpler.

I call it as 

python2.7 "/home/gedae/ti/mcsdk_2_01_02_06/tools/boot_loader/mad-utils/map-tool/maptool.py" /home/gedae/gedev/system/redhat/ti_c6678/bin/maptoolCfg.json bypass-prelink

Hi James,

    Thank you for your reply!

    I'm using MCSDK2.1.2.6, and rebuilding the mad image for the image processing demo based IPC. I have tried the prelink bypass mode, I execute the "build_mad_image_prelink_bypass.bat" file :

@set PATH="D:\ti\ccsv5\tools\compiler\c6000_7.4.1\bin";%PATH%

@rd /s /q tmp

python ..\..\..\..\..\tools\boot_loader\mad-utils\map-tool\maptool.py config-files\maptoolCfg_evmc6678l_bypass_prelink.json bypass-prelink

and the image "mcip-plbp-c6678-le.bin"was generated successfully , and worked profectly on my 6678EVM.

So, the effects of the two mode (prelinker bypass and prelinker ) are the same , am I right? In my future design , I just use the prelinker bypass mode to generate the mad image, is it OK? (Question1)

I imported the image processing demo in the CCS, and rebuilt it. it built the executable image_processing_evmc6678l_master.out and image_processing_evmc6678l_slave.out, then I executed the build_mad_image.bat (python ..\..\..\..\..\tools\boot_loader\mad-utils\map-tool\maptool.py config-files\maptoolCfg_evmc6678l.json), and it displayed the error in my last post. Is it  the problem that the executable were not build as dynamic and relocatable ?

And you  said "You would pass --dynamic and --relocatable to cl6x when you link the executable",  so how do I set these parameters when I build the executable?(Question2)

Thanks very much!

Regards

Eric