• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 102 subscribers
  • Views 1044 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

migration to SYS/BIOS - linking my own startup code

Richard Dobbis
Intellectual 460 points
Other Parts Discussed in Thread: SYSBIOS

I am building a DSP/BIOS project using SYS/BIOS (CCSv5). I have conquered the configuration conversions and seem to be compiling the source code just fine. The original project has a boot file in it that looks to be copies of some of the initial startup functions - taken directly from DSP/BIOS source code. Now, when I link, I get:

error #10056: symbol "_c_int00" redefined: first defined in "./boot.obj"; redefined in "C:\ti\bios_6_35_04_50\packages\ti\bios\support\lib\release\ti.bios.support.a64P<boot.o64P>"
error #10056: symbol "__stack" redefined: first defined in "./boot.obj"; redefined in "C:\ti\bios_6_35_04_50\packages\ti\bios\support\lib\release\ti.bios.support.a64P<boot.o64P>"
error #10056: symbol "__auto_init" redefined: first defined in "./autoinit.obj"; redefined in "C:\ti\xdctools_3_23_04_60\packages\ti\targets\rts6000\lib\boot.a64P<autoinit.o64P>"
warning #10247-D: creating output section ".bios" without a SECTIONS specification

How can I change the settings for the linker phase such that it doesn't pull-in the SYS/BIOS versions of those functions ?

Thanks !!

  • 0
    TI__Mastermind 45025 points
    Richard,

    As you're migrating to SYS/BIOS, I don't think you should use those boot files that look to be from DSP/BIOS. You should use the boot files in the legacy support layer, as they are meant to work with SYS/BIOS (the ti.bios.support.a64P, etc. files are the ones to use).

    Steve
  • 0 in reply to Steven Connell
    Intellectual 460 points
    Steve

    So, do you mean that if I update my boot.c and autoinit.c source files - to those from SysBios, rewrite them as neede to support our usage, and recompile, that the linker will no longer try to pull-in those files from the support library - but instead use mine ? We have a lot of custom code that we inserted in those two source files so I can abandon using them directly.

    Richard
  • 0 in reply to Richard Dobbis
    TI__Mastermind 45025 points
    Ok, I didn't realize you had done a lot of custom code in your boot.c file.

    Is there any reference to the ti.bios.support package in your *.cfg file? Or the modules contained within? (ti.bios.support.Lck.xdc/.Sys.xdc)

    Steve
  • 0 in reply to Steven Connell
    Intellectual 460 points
    Steven

    I don't think so. I am not sure I understand the question but I grep'd for the word 'support' in my <proj>.cfg file and nothing came up.

    Refresh - perhaps what I am asking is for a pointer to documentation about substituting my own "boot.c" file for the one in the <SYS/BIOS> library. I do see that there is a "boot.c" file in the <SYS/BIOS>/packages/ti/bios/support directory and I hope that means that this can be done (just like <SYS/BIOS>/packages/ti/bios/support/Lck.c is there as a guide to migrating the old LCKs to the new functions).

    Thanks
    Richard
  • 0 in reply to Richard Dobbis
    TI__Mastermind 30830 points
    Richard,

    Steve is out on paternity leave for awhile. I'm hoping I can help you out here.

    The boot.c code in the support directory allows you to plug in custom startup code at several places within the boot sequence.

    The earliest point to add code is with a Reset.fxns hook.
    Reset functions are added statically within the .cfg file:

    var Reset = xdc.useModule("xdc.runtime.Reset");
    Reset.fxns[Reset.fxns.length++] = "&myReset";

    The Reset functions are executed prior to cinit so be careful not to reference any initialized variables in the Reset function code.

    The next point to add code is in the Startup.firstFxn list:

    var Startup = xdc.useModule('xdc.runtime.Startup');
    Startup.firstFxns[Startup.firstFxns.length++] = "&myFirst";

    The Startup.firstFxns are called after cinit and autoinit, but before all of the BIOS and XDC RUNTIME module initialization functions.

    I'm hoping that using these two boot up hook function entry points will be sufficient for your purposes rather than rewriting boot.c.

    Alan
  • 0 in reply to Alan DeMars
    Intellectual 460 points
    Alan

    Thanks for the pointers on how to hook into the existing code. That may be sufficient to handle our custom code but I would still like to know more about the support code - for example, is it provided as an alternative to the normal build ? Can I add code to the boot.c file in the support directory and then command the tools to build and link THAT file ? Also, I would think that if I provide my own boot.c, complete with all the proper functions and symbols, that the linker would not need to pull in the TI provided boot.c BUT that does not seem to be the case. I am also having some trouble with providing additional SECTIONs but I admit that I haven't read all the documentation on that yet.

    Thanks
    Richard
  • 0 in reply to Richard Dobbis
    TI__Mastermind 30830 points

    Richard,

    Sorry for the delayed response. Have you made any progress on this?

    Yes, you should be able to modify boot.c and rebuild the your BIOS installation to include those changes. Follow the instructions in appendix A of the SYS/BIOS User's Guide to rebuild BIOS after you've made your changes.


    Alan