• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 98 subscribers
  • Views 818 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.

Rebuilding NDK2.1 without printf's with BIOS6

Nick Borton
Genius 3595 points
Other Parts Discussed in Thread: SYSBIOS

I have downloaded and sucessfully used the NDK2.1 libs with an EVM6472 and BIOS6. What I would like to do is remove all instances of printf's in NDK, and possibly replace them with LOG_Print's.

My first attempt was to just add the source which cam in the tar file, and added it to my project. This caused all sorts of issues since all of the header files in the source appears to be BIOS5 based, and not BIOS6. After I managed to replace all of the BIOS5 headers with BIOS6 headers, then came all of the errors duw to the API differences (I am guessing). Now it is getting beyond my ability to fix in a short amount of time.

Is there a proper way to rebuild the NDK for BIOS6 of which I am unaware, and have been unable to track down on either the wiki or the forum?

  • 0
    TI__Guru*** 125430 points

    Here's what I just tried:

    • Opened a command window to the ti/ndk directory of NDK 2.1.
    • Edited setupenv.bat and modified all the variables to point to corresponding paths on my machine (e.g. BIOS 5, BIOS 6, codegen, xdctools, etc.)
    • Do a find/replace in setupenv.bat to make sure that all occurrences of '\' are changed to '/'.  Things were getting messed up using the typical windows slash...
    • Run setupenv.bat from your command prompt to setup the appropriate variables.
    • Run "xdc" command (assuming xdctools is on your Windows path).

    That should cause a rebuild of the entire library.  Mine has been building for 15 minutes or so.  I *think* I've covered all the main steps.

    If this doesn't work please copy/paste your specific error message.  Also, I wasn't sure what you were talking about when you mentioned changing all the header files from BIOS 5 to BIOS 6 headers.  Please specify the file.

    Brad

  • 0 in reply to Brad Griffis
    Genius 3595 points

    It looks like that did end up rebuilding everything. Although I still got an error dealing with the benchmarking, which isn't too important to me:

    ofd6x: not found
    gmake.exe: *** [benchmarking_C64PminiPrintf] Error 127

    Now I also have a lot of learning to do in terms of the xdc tool.

    Some commentary: This is certainly not as simple as a makefile where you can quickly understand where the source came from, what it depends on, where it is installed to, and ultimately how it is really built. The auto generated makefiles are no where near as clean or understandable as makefile written by real developers. My inability to just include the NDK source in my project even shows how the xdc method intrudes into the code.

  • 0 in reply to Nick Borton
    TI__Guru*** 125430 points

    I had to paste my compiler path a total of 3 times:

    • Once into XDCCGROOT
    • Twice into the PATH variable further down

    The ofd6x.exe utility is part of the code generation tools so your error is probably due to not adding it to the PATH, at least that's what I would assume.

    I agree with you that the xdctools can be difficult to learn.  We are continually working to improve documentation, primers, wizards, IDE integration, etc.  We're not there yet, but we hope to make it easier for people to use xdctools in the future.

  • 0 in reply to Brad Griffis
    Genius 3595 points

    Do  you have any links to TI specific xdctool documents or training? A quick search of the wiki only brought up "Using XDCtools with BIOS 5" which leaves a bit to be desired.

    I appreciate the efforts you guys go to to make these "integrated" environments, but to me, while they get you going quickly, they obscure even further what is really happenning. I am not sure what files I need to CM, and how my few test programs on my EVM are really built. In general IDE files are none too happy about being CMed and then have multiple developers modify them in different manners and then have to be merged.......

  • 0 in reply to Nick Borton
    TI__Guru*** 125430 points

    It's actually all bundled inside the product.  I recommend looking at the documentation with the very latest version of the xdctools since they frequently improve it.  Start here:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/

    Click on the latest version.  They allow you to download the documentation separately if that's all you're looking for.  I like the chm version for browsing in Windows.

    Brad

  • 0 in reply to Brad Griffis
    Prodigy 200 points

    Hi Brad,

     

    I followed your steps to rebuild the NDK. I'm rebuilding NDK 2.1.0. Everything builds fine until here:

    ...

    archiving package/lib/./lib/C64plus/hal/hal_timer_bios5/src/hal/timer_bios/lltimer.o64P package/lib/./lib/C64plus/hal/ha
    l_timer_bios5/package/package_ti.ndk.o64P into lib/C64plus/hal/hal_timer_bios5.lib ...
    cl64P package/package_ti.ndk.c ...
    cl64P src/hal/userled_stub/llled.c ...
    "src/hal/userled_stub/llled.c", line 49: remark #880-D: parameter "ledId" was never referenced
    "src/hal/userled_stub/llled.c", line 50: remark #880-D: parameter "ledId" was never referenced
    "src/hal/userled_stub/llled.c", line 51: remark #880-D: parameter "ledId" was never referenced
    archiving package/lib/./lib/C64plus/hal/hal_userled_stub/package/package_ti.ndk.o64P package/lib/./lib/C64plus/hal/hal_u
    serled_stub/src/hal/userled_stub/llled.o64P into lib/C64plus/hal/hal_userled_stub.lib ...
    process_begin: CreateProcess(NULL, cl example/tools/common/binsrc/binsrc.c /Feexample/tools/common/binsrc/binsrc.exe, ..
    .) failed.
    make (e=2): The system cannot find the file specified.
    gmake.exe: *** [example_prologue] Error 2

     

    Do you know what this error is stemming from?

     

    Thanks, Peter

  • 0 in reply to Peter Sommerfeld63615
    TI__Guru*** 125430 points

    Peter,

    To be honest, I'm not sure what that error is all about.  We'd need someone else to help diagnose the issue.  However, I think there's a better alternative.  There are newer versions of the NDK available.  Currently NDK 2.20.03 is the latest release.  There are a couple significant additions to the 2.20.x branch of the NDK:

    1. Support for sysbios (i.e. bios 6.30+)
    2. CCS projects for rebuilding the libraries

    Hopefully that will resolve your issue.  However, if your issue is part of the "Network Support Package" then that won't be resolved by the update.  I'm not an NDK expert but I imagine there's not a lot of other people working this holiday week so I might be your best support option for now!  ;)

    Best regards,
    Brad

  • 0 in reply to Brad Griffis
    Prodigy 200 points

    Hi Brad,

     

    I sure appreciate your prompt reply. I've installed the new release.

     

    It looks like raw sockets are not supported in the DaemonNew call in daemon.c (ie. the SOCK_RAW type). Is there a reason for this?

     

    My application likely requires raw socket communication to achieve the necessary level of efficiency.

     

    Thanks, Peter

  • 0 in reply to Peter Sommerfeld63615
    TI__Guru*** 125430 points

    Peter,

    I recommend starting a new thread related to your question on raw sockets for 2 reasons:

    1. The topic differs from the subject of this thread.
    2. This thread already has a "verified answer".  Therefore most TI people won't even look in this thread because the "verified answer" indicates that the question is resolved.  In general for this reason it's in your best interest to always start a new thread and reference any related threads as necessary.

    Best regards,
    Brad

  • 0 in reply to Peter Sommerfeld63615
    Prodigy 200 points

    That makes sense. I'll repost to a new thread.