• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 96 subscribers
  • Views 1230 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/PROCESSOR-SDK-AM437X: RTOS build dependency on workspace path

Marcio Borges
Expert 1950 points

Part Number: PROCESSOR-SDK-AM437X
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

Hi,

 I did an exercise of reproducing my development environment into different machines.

 When I´ve build my application using the Release configuration, I´ve got different outputs depending on the workspace path.

 I understand that the “.out” file has symbols, but the binary files are different too. The binary files were obtained using objcopy.exe and tiimage.exe.

 These are the compile command flags for the Release configuration:

 -mcpu=cortex-a9 -mtune=cortex-a9 -march=armv7-a -marm -mfloat-abi=hard -Dam4378 -DSOC_AM437x -DSK_AM437X -D_USE_WDT_ -I"C:/ALSTOM/CED2/Workspace/ced2_v1000_beta4" -I"C:/ti/gcc-arm-none-eabi-4_9-2015q3/arm-none-eabi/include" -O2 -Wall -std=c++11

and

-mcpu=cortex-a9 -mtune=cortex-a9 -march=armv7-a -marm -mfloat-abi=hard -Dam4378 -DSOC_AM437x -DSK_AM437X -D_USE_WDT_ -I"C:/Users/mborges/workspace_v7/ced2_v1000_beta4" -I"C:/ti/gcc-arm-none-eabi-4_9-2015q3/arm-none-eabi/include" -O2 -Wall -std=c++11

 

These are the link command flags:

 -mtune=cortex-a9 -marm -Dam4378 -DSOC_AM437x -DSK_AM437X -D_USE_WDT_ -O2 -Wall -std=c++11 -mfloat-abi=hard -Wl,-Map,"ced2.map" -nostartfiles -static -Wl,--gc-sections -L"C:/ti/bios_6_46_05_55/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu" -Wl,--defsym,STACKSIZE=0x18000 -Wl,--defsym,HEAPSIZE=0x400

 and

-mtune=cortex-a9 -marm -Dam4378 -DSOC_AM437x -DSK_AM437X -D_USE_WDT_ -O2 -Wall -std=c++11 -mfloat-abi=hard -Wl,-Map,"ced2.map" -nostartfiles -static -Wl,--gc-sections -L"C:/ti/bios_6_46_05_55/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/fpu" -Wl,--defsym,STACKSIZE=0x18000 -Wl,--defsym,HEAPSIZE=0x400

 

Please check out these 2 map files attached. The length of "xdc.meta" are different by the exact difference of chars in the workspace path (5 chars). The rest of the code is shifted.

 map.zip

Is there any explanation/reason for that?

Installed items:

CCS 7.2

GCC ARM Compiler 4.9.3

processor_sdk_rtos_am437x 4.00.00.04

am437x PDK v1.0.7

bios 6.46.05.55

xdctools 3.32.02.25_core

regards,

Marcio.

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru* 95265 points
    Hi,

    How the binary files different after conversion? Does the different *.out files causing any issue when run?

    Regards, Eric
  • 0 in reply to lding
    Expert 1950 points

    Hi Eric,

    Apparently both binary files run ok.

    The test team found the difference on the binary files, when they were trying to recreate the development environment in another machine.

    If you look the map files, the size of the xdc.meta section is diffrent depending on the workspace path.

    For instance, if the path of a workspace is 5 chars longer, then the size of  xdc.meta will be 5 chars longer too. Consequently the .c_int00 will be shifted in 5 bytes. I guess the linker carries this difference to the .out file and consequently to the binary file.

    I think the path comes from sysbios.aa9fg. It has several strings containing paths, even if I do a Release build in CCS.

    Edited 2018-04-04:
    Attaching the bin file. I do not see any reference to the path inside the file.ced2.zip


    regards,
    Marcio.

  • 0 in reply to Marcio Borges
    TI__Guru* 95265 points
    Hi,

    In the .map file, I saw the shift of 5 bytes due to xdc.meta section from different installation path. Do you have the command used for objcopy and tiimage, or you just use the pdkAppImageCreate batch script?

    Your attached binary only have one bin file, can you attach both to see the difference? If you look the ti_image.c under pdk_am437x_1_0_x\packages\ti\starterware\tools\ti_image, it is a simple C file to add some header. The ARM objcopy which could cause the binary difference.

    Regards, Eric
  • 0 in reply to lding
    Expert 1950 points

    6165.CED2.ZIP

    Hi Eric,

    I use a batch file to convert the .out file:

    set buildName=ced2

    set projOutPath=%CD%\Release

    set tiPath=c:\ti

    set pdkPath=%tiPath%\pdk_am437x_1_0_7

    set toolChainPath=%tiPath%\gcc-arm-none-eabi-4_9-2015q3\bin

    set tiimagePath=%pdkpath%\packages\ti\starterware\tools\ti_image

    %toolChainPath%\arm-none-eabi-objcopy.exe -O binary %projOutPath%\%buildName%.out %buildName%.bin

    %tiimagePath%\tiimage.exe 0x80000000 NONE %buildName%.bin %buildName%_ti.bin

    I thought objcopy only translates the .out file and it not change the result of the linker.

    I´ve attached all set of files.

    regards,

    Marcio.

  • 0 in reply to Marcio Borges
    TI__Guru* 95265 points
    Hi,

    I used diff -y <(xxd ced2_1.bin) <(xxd ced2_2.bin) | colordiff to compared the two binaries, the difference is mainly the data shift. From the manned.org/arm-none-eabi-objcopy

    objcopy can be used to generate a raw binary file by using an output
    target of binary (e.g., use -O binary). When objcopy generates a raw
    binary file, it will essentially produce a memory dump of the contents of
    the input object file. All symbols and relocation information will be
    discarded. The memory dump will start at the load address of the lowest
    section copied into the output file.

    So the symbols are not there anymore, I am not sure how the binaries are different. But this objcopy is not TI tool, also the linker is from GNU ARM, we may not have a definite answer for this.

    Regards, Eric
  • 0 in reply to lding
    Expert 1950 points

    Hi Eric,

    I understand. I hope there isn´t a bug in the linker.

    For now, I will recommend to our team to create the workspace using a standard path. I believe this is sufficient to recreate the binary file and certify that the development environment is installed correctly.

    regards,
    Marcio.