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.

Command-line build including SYS/BIOS for C6657, under Linux

Other Parts Discussed in Thread: SYSBIOS

Hello,6320.buildout.txt4846.makefile.txt

I am using the C6657 EVM and have been running test code on it using CCS 6.1.3, with xdctools 3.32, ndk 2.24 and bios 6.45. The example code is from pdk_c665x_2_0_1. In particular I have run the NIMU_emacExample_EVMC6657C66BiosExampleProject example and have UDP loopback running. My development is done on a Windows 7 PC.

Our goal is to move to a command-line build on a Linux PC. We have a command-line build working using ti-cgt-c6000_8.1.1 for a simple project without SYS/BIOS and without NDK. The Linux PC has the packages xdctools_3_32_00_06_core_linux.zip and bios_setuplinux_6_46_00_23.bin and ndk_2_25_00_09.zip installed (i.e. unzipped etc.). My question is how to build a project which uses SYS/BIOS and the NDK in this Linux command-line build environment.

I have looked at the link http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs#7_How_to_build_SYS.2FBIOS_apps_on_Linux_using_an_external_makefile

I downloaded the example file Example.tar.gz and unzipped it on the Linux machine. I modified the makefile (attached and renamed to makefile.txt) to point to my tools and be for the C66x target. Running “make” using this modified makefile fails (build output attached). Am I on the right track? I expect the failure is because of something unrelated. If this is the right track, can you provide a makefile which would be suitable for a C6657?

I have seen references which seem to imply that you need to use eclipse with commands which start with “eclipsec -noSplash” such as http://processors.wiki.ti.com/index.php/Projects_-_Command_Line_Build/Create. This page also has many references to importing projects. So I am not sure if I need to start with a CCS project which includes SYS/BIOS and the NDK and then import that to a command-line build.

I have also seen a suggestion to run gmake using makefiles generated in CCS in http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/254552

This would again imply that starting from CCS is the right approach. We prefer not to do that if possible. Any guidance would be appreciated.

Thanks,
Geraldine

  • I should add that I've looked at section 2.4.3 "Building an Application with GCC" in spruex3q.pdf and at the link processors.wiki.ti.com/.../BIOS_with_GCC which discusses only the Cortex families.
    Also, we don't want to rebuild SYS/BIOS, we just want to use its functionality.
  • Hi Geraldine,

    The build from the Example.tar.gz seems to be complaining about not finding the .rov.xs file. Can you try commenting out the cp command in the makefile and see if the rest compiles and runs fine?

    Regards,
    Gilbert
  • Hello Gilbert,

    After commenting out the cp command the build goes further then fails due to undefined symbols. I am attaching the new build output and the very limited c66x.cmd file which is referenced in the makefile.

    Regards,
    Geraldine7607.c66x.cmd.txt8420.buildout2.txt

  • Geraldine,
    I think the current problem is that your linker command line is missing $(RTSLIB). Look at the commented linker command line for CortexM3 and you'll notice the difference. So, you first have to define RTSLIB to point to the right library. I think in your case it should be
    $(C6XTOOLS)/lib/libc.a

    The linker will translate 'libc.a' to the right rts library.

    I don't know what's in your sysbios/linker.cmd file, but the content of it may clash with c66x.cmd. If both these files are trying to specify the memory layout and allocate the same sections, you may get an error. But try adding libc.a first and then we'll see what happens.

  • 8738.ndkTestProject.zipHello Sasha,

    Thanks for your reply. We have made some progress but are stuck with a new problem. I added RTSLIB as you suggested. The source files and the build output are attached in ndkTestProject.zip.

    The first couple of lines showing undefined symbols from the build output are:

    Convert_CoreLocal2GlobalAddr /opt/ivy-tools/ti/pdk_c665x_2_0_2/packages/ti/transport/ndk/nimu/lib/c6657/c66/release/ti.transport.ndk.nimu.ae66<nimu_eth.oe66>
    Interrupt_add /opt/ivy-tools/ti/pdk_c665x_2_0_2/packages/ti/transport/ndk/nimu/lib/c6657/c66/release/ti.transport.ndk.nimu.ae66<nimu_eth.oe66>

    We have searched through the source code for the various symbols which show as undefined and can find them referenced as "extern" in header files but can't find the actual function definitions. I am currently trying to rebuild the NDK and PDK on my Linux build machine because I thought the libraries might contain paths which aren't valid on my build machine. Does this make sense? I was able to rebuild the NDK using the steps here (processors.wiki.ti.com/.../Rebuilding_The_NDK_Core_Using_Gmake)  however following the steps for rebuilding the PDK is not going well (processors.wiki.ti.com/.../Rebuilding_The_PDK). I am assuming I need to rebuild the PDK because this is where the NIMU transport folder is e.g. I:\ti\pdk_c665x_2_0_2\packages\ti\transport\ndk\nimu on my build machine.  

    Rebuilding the PDK I have just gone as far as the build setup step and there are paths I am not sure of:

    [root@localhost packages]# ./pdksetupenv.sh
    Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
    REQUIRED for xdc release build
    Example: export CG_XML_BIN_INSTALL_PATH="~/ti/cg_xml/bin"
    Optional parameter not configured : DOXYGEN_INSTALL_PATH
    REQUIRED for xdc release build
    Example: export DOXYGEN_INSTALL_PATH="~/ti/Doxygen/doxygen/1.5.1-p1/bin"
    **************************************************************************
    Environment Configuration:
    LIMIT_SOCS : c665x
    LIMIT_BOARDS : evmC6657
    PDK_INSTALL_PATH : /opt/ivy-tools/ti/pdk_c665x_2_0_2/packages
    C6X_GEN_INSTALL_PATH : /opt/ivy-tools/ti/ti-cgt-c6000_8.1.1
    TOOLCHAIN_PATH_A15 : /opt/ivy-tools/ti//ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3
    TOOLCHAIN_PATH_A8 : /opt/ivy-tools/ti//ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3
    TOOLCHAIN_PATH_A9 : /opt/ivy-tools/ti//ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3
    TOOLCHAIN_PATH_M4 : /opt/ivy-tools/ti//ccsv6/tools/compiler/ti-cgt-arm_15.12.1.LTS
    FPULIB_PATH : /opt/ivy-tools/ti//ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/lib/gcc/arm-none-eabi/4.9.3/fpu
    CROSS_TOOL_PRFX : arm-none-eabi-
    XDC_INSTALL_PATH : /opt/ivy-tools/ti//xdctools_3_32_00_06_core
    BIOS_INSTALL_PATH : /opt/ivy-tools/ti//bios_6_46_00_23
    IPC_INSTALL_PATH : /opt/ivy-tools/ti//ipc_3_43_01_03
    EDMA3LLD_BIOS6_INSTALLDIR : /opt/ivy-tools/ti//edma3_lld_2_12_01_24
    NDK_INSTALL_PATH : /opt/ivy-tools/ti//ndk_2_24_03_35
    IMGLIB_INSTALL_PATH : /opt/ivy-tools/ti//imglib_c66x_3_1_1_0
    UIA_INSTALL_PATH : /opt/ivy-tools/ti//uia_2_00_03_43
    PDK BUILD ENVIRONMENT CONFIGURED
    *******************************************************************************

    In particular, the TOOLCHAIN paths. I then thought I would try just rebuilding NIMU and I found a makefile in the folder I:\ti\pdk_c665x_2_0_2\packages\ti\transport\ndk\nimu.  I have renamed and attached this makefile which I edited to point to my paths. Running this build gives the attached nimu_buildOut.txt output. Again the failure relates to a tool I don't recognize: "make[4]: /opt/tools/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-gcc: Command not found"  

    I am not sure how to proceed or if I'm on the right track. My goal is to get the ndkTest project working which is in the attached zip file. I'm trying to rebuild PDK and NIMU to solve that problem but that may be the wrong approach.

    Thanks,
    Geraldine
    6012.nimu_buildOut.txt3276.nimu_makefile.txt

  • The link processors.wiki.ti.com/.../Rebuilding_The_PDK has paths like this:
    /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    I checked on my Windows PC which has CCS installed and under the path C:\ti\ccsv6\tools\compiler I do not see a sub-folder like this. I only see the sub-folders dmed, ti-cgt-c6000_8.1.0 and ti-cgt-c6000_8.1.1.
  • Hi Geraldine,

    It looks like you can build the PDK for a specific component, so you likely do not need the paths for the other toolchains. Just setting the TI compiler for your device should be enough.

    Regards,
    Gilbert
  • Hello Gilbert,

    I thought I was rebuilding for a specific component i.e. NIMU. "I then thought I would try just rebuilding NIMU and I found a makefile in the folder I:\ti\pdk_c665x_2_0_2\packages\ti\transport\ndk\nimu. I have renamed and attached this makefile which I edited to point to my paths. Running this build gives the attached nimu_buildOut.txt output. Again the failure relates to a tool I don't recognize: "make[4]: /opt/tools/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-gcc: Command not found" "
    Is this what you meant? I get failures for that too.

    Thanks,
    Geraldine
  • For some reason, it seems like make is attempting to build for an am572x platform, which would require the gcc-arm-none-* to be set for the A15 toolchain. Can you try cleaning the project, re-running the pdksetupenv.sh script, and trying again? If that does not work, can you try "make c665x"?

    Regards,
    Gilbert
  • Hello Gilbert,

    A quick check trying one of your suggestions for NIMU gives an error:
    [root@localhost nimu]# make c665x
    make: *** No rule to make target `c665x'. Stop.
    [root@localhost nimu]# pwd
    /opt/ivy-tools/ti/pdk_c665x_2_0_2/packages/ti/transport/ndk/nimu

    Before I look further into this, can you confirm that this is the right approach to solving the original problem I'm trying to solve (at the top of my 31 Aug post), i.e.
    "The first couple of lines showing undefined symbols from the build output are:
    Convert_CoreLocal2GlobalAddr /opt/ivy-tools/ti/pdk_c665x_2_0_2/packages/ti/transport/ndk/nimu/lib/c6657/c66/release/ti.transport.ndk.nimu.ae66<nimu_eth.oe66>
    Interrupt_add /opt/ivy-tools/ti/pdk_c665x_2_0_2/packages/ti/transport/ndk/nimu/lib/c6657/c66/release/ti.transport.ndk.nimu.ae66<nimu_eth.oe66>
    etc."

    Thanks,
    Geraldine
  • Hi Geraldine,

    Apologies for the delay. Can you check to see if you have NDK's OS lib generated? It should be in <path_to_ndk>/os/lib/os*.lib. Can you also check to see if the os lib is being linked in the linker command file? It would be helpful if you posted that too. As for the PDK question, I will get back to you once I get some more information.

    Regards,
    Gilbert
  • 8080.linker.cmd.txtHello Gilbert,

    The attached file is the linker.cmd file which gets generated by the build and placed into the sysbios folder. It is used together with the c66x.cmd file which is in  ndkTestProject.zip attached in 31 Aug. This all relates to the issue of undefined symbols from the build output, e.g.:

    Convert_CoreLocal2GlobalAddr /opt/ivy-tools/ti/pdk_c665x_2_0_2/packages/ti/transport/ndk/nimu/lib/c6657/c66/release/ti.transport.ndk.nimu.ae66<nimu_eth.oe66>

    In the folder /opt/ivy-tools/ti/ndk_2_25_00_09/packages/ti/ndk/os/lib I see these four files (all dated 30 Aug):

    os.ae66,  os.ae66.mak,  os_sem.ae66,  os_sem.ae66.mak

    Does this answer your questions?

    Thanks,
    Geraldine

  • I've talked to some of my colleagues and it seems like we don't handle the PDK. The PDK was developed by people who were familiar with the processor, so you would likely getting better help from the device forums found here: e2e.ti.com/.../639

    Regards,
    Gilbert
  • Hello Gilbert, can you move this thread for me or do I need to start a new one in the device forums? I don't see an option to move a thread.
    Thanks,
    Geraldine
  • For the PDK question, it would be best to start a new question.

    In the meantime, we can still help you with anything SYSBIOS/NDK releated. Can you update your main project makefile to include "LNKOPTS = -x"?

    Regards,
    Gilbert
  • Hello Gilbert,

    I have added the “-x” option to the LNKOPTS line in the makefile:

    LNKOPTS = -x

    This did not have any noticeable effect. The list of unresolved symbols remained the same.

    I found how to get rid of the undefined symbols efs_fclose, efs_filecheck, efs_filesend, efs_fopen, efs_getfilesize and efs_loadfunction. Adding “--priority” to the linker line fixed this.

    I am attaching example2.zip which is a very simple project. There is a single line in the single .c file which determines whether these symbols will be unresolved during the linker stage: Convert_CoreLocal2GlobalAddr, Osal_beginMemAccess, Osal_endMemAccess, Osal_enterMultipleCoreCriticalSection, Osal_enterSingleCoreCriticalSection, Osal_exitMultipleCoreCriticalSection, Osal_exitSingleCoreCriticalSection, Osal_free and Osal_malloc.

    If I comment out that line the build finishes. If the line is uncommented the build fails with those symbols unresolved. The line is:

    NC_SystemOpen( NC_PRIORITY_LOW, NC_OPMODE_INTERRUPT );

    Since this is a function defined in the NDK Reference and User’s guides, I think this is an NDK question and not a PDK one. Is that correct?

    So I'm still asking about the linker unresolved symbol errors. If this is a PDK question I will post this in a different forum.

    Thanks,
    Geraldine

    4454.example2.zip

  • Hi Geraldine,

    Can you create a successful build and attach the map file? I don't expect NC_SystemOpen() to be calling Osal functions, but the map file would help determine the issue.

    Regards,

    Gilbert

  • Hello Gilbert,

    I have attached map files for the successful and failing builds (successful from commenting out the call to NC_SystemOpen). I have been trying to figure out the link to Osal and don't understand it. I found those symbols in the library "/opt/ivy-tools/ti/pdk_c665x_2_0_2/packages/ti/drv/emac/lib/c6657/c66/ti.drv.emac.c6657.ae66" which is indeed being included. Maybe the order is incorrect? But still, knowing why they are being used in the first place would be good.

    Thanks,

    Geraldine

    0045.ndkTest.map.fails.txt0755.ndkTest.map.succeeds.txt

  • Adding this line to c66x.cmd:
    -l"/opt/ivy-tools/ti/pdk_c665x_2_0_2/packages/ti/platform/evmc6657l/platform_lib/lib/release/ti.platform.evm6657l.ae66"
    removes the Convert_CoreLocal2GlobalAddr undefined symbol.

    So just the Osal undefined symbols are still an issue (Osal_beginMemAccess, Osal_endMemAccess, Osal_enterMultipleCoreCriticalSection, Osal_enterSingleCoreCriticalSection, Osal_exitMultipleCoreCriticalSection, Osal_exitSingleCoreCriticalSection, Osal_free and Osal_malloc).
  • Hi Gerlaldine,

    Can you please zip up and attach your entire project that demonstrates this problem?

    Please attach the successfully built version of the project (with NC_SystemOpen() commented out).


    Thanks

    Steve

  • 1072.example3.zip

    Hello Steve,

    I have zipped up the project for the working case.

    In the meantime we found a workaround but it seems unwieldy, and if this is the only way to resolve things we'd like to understand why. The unresolved symbols are all defined as functions in the file 

    pdk_c665x_2_0_2/packages/ti/transport/ndk/nimu/example/helloWorld/src/nimu_osal_c6657.c

    If we include that file in our project, the build finishes without any errors. Many of the functions in this file look like stubs. Why would they be needed if the project is including the OSAL library? The generated linker.cmd file includes this line:

    -l"/opt/ivy-tools/ti/pdk_c665x_2_0_2/packages/ti/osal/lib/tirtos/c66/release/ti.osal.ae66"

    Thanks,

    Geraldine

  • Is there any update on this?

    Thanks,
    Geraldine

  • Hi Geraldine,

    I took a look at the Processor SDK install, and the PDK sub-product.  I see that the OSAL functions are indeed defined in that example source file, as you mentioned above.  I'm not sure why these functions are being defined in an example like this.

    I also see that there are other Osal functions defined in the file pdk_c665x_2_0_2\packages\ti\transport\ndk\nimu\example\src\nimu_osal.c

    Again, I'm not sure why the PDK team is defining these APIs as part of an example.  It seems these should be part of the NIMU driver (Ethernet driver).

    Geraldine Maclear said:
    If we include that file in our project, the build finishes without any errors.

    Many of the functions in this file look like stubs. Why would they be needed if the project is including the OSAL library? The generated linker.cmd file includes this line:

    -l"/opt/ivy-tools/ti/pdk_c665x_2_0_2/packages/ti/osal/lib/tirtos/c66/release/ti.osal.ae66"

    In any case, based on this, it seems that the missing code is indeed in the PDK.  I think the problem is that your app just isn't linking all of the libraries that are required.  Note that the above library doesn't look to have those Osal_* symbols defined, either.

    I guess it's possible that the PDK requires you to build the nimu_osal*.c files into the application, but I'm not sure, as I'm not familiar with this product.

    I think the best option at this point is to ask the PDK team what libraries are needed to resolve these undefined symbols, and what are the best means of getting those libraries linked in (or, the best way to resolve these Osal* symbols).


    Cheers,

    Steve