Required projects for SysBios (6.3x)

Hi Calvin,

You may want to refer to http://rtsc.eclipse.org/docs-tip/Memory_Management for an overview of memory management in RTSC. This covers information on how to use your own linker command file with RTSC.

It may also help to go through the documentation in http://rtsc.eclipse.org/docs-tip/RTSC%2BCCStudio_v4_QuickStart. To get started quickly I would recommend using the starter examples shipped with SYS/BIOS and then add your own content to it.

Regards

Amit

Thanks for the quick repsonses. After studying the examples I'm more confortable with porting the "BIOS" features (task, swi, etc). However, to support compiling the same project for multiple cores (TCI6486) I had to use a the environment variable and conditional compile features of TCONF to set the base address of DDR2 memory to the correct portion of memory allocated for each core. Amit, I think you mentioned to me a year ago that I might be able to do the same thing in the config.bld using if (environment['CORE'] == 0) {} but I'm not sure where I would add this? Is it to the config.bld that is part of the platform package? Would this get rebuilt each time I compile? I have a custom platform created that has the base memory map (SL2RAM LL2RAM, DDR2) defined. Can I use that as the Build.platformTable[] and modify just the DDR2 sections in the config.bld?

In the meantime, more reading. thanks for the links.

Thanks,

Calvin

Sahsh, Amit,

In terms of mapping sections to physical memory, is there any functional difference between using a user specified link.cmd file and Progam.sectMap[]? I seem to get the same desired results either way but was not sure if there are benefits or unseen side effects of using one method over the other.

Thanks,

Calvin

Calvin,

You are correct. Specifying sections via Program.sectMap and your own linker command file is functionally equivalent. The RTSC tools in the end will generate a linker command file of it own based on what is specified in Program.sectMap. Note that the linker command file provides a very rich set of capabilities that is not all covered by RTSC objects accessed via the config script.

So if you are just mapping few sections of your own using Program.sectMap is good enough. However, when you try to use advanced capabilities of the linker it may make sense to provide a linker command file of your own.

Regards

Amit

Great! Thanks for the clarification.

-Calvin

Yes, you can modify Build.platformTable[] entry for your custom platform in config.bld. The exact steps depend on how and where did you define your custom platform, but most likely you would be using the following platform parameters: http://rtsc.eclipse.org/cdoc-tip/xdc/platform/IPlatform.html#custom.Memory.Map and http://rtsc.eclipse.org/cdoc-tip/xdc/platform/IPlatform.html#external.Memory.Map.

You would have something like this in your config.bld:

if (environment['CORE'] == 0) {
    Build.platformTable["myplatforms.custom"] = {
        externalMemoryMap: [
            [
                "DDR2",
               {
                    name: " DDR2 ",
                    base: 0x80000000,
                    len:     0x00800000,
                    space: "code/data",
                }
            ]
        ]
    };
}
else {...}

Also, in your project's Build Properties, you'll have to add property CORE and you'll have to keep changing it whenever you decide to build for a different core.

The file config.bld is reread every time you build.

CalvinC said:

I think you mentioned to me a year ago that I might be able to do the same thing in the config.bld using if (environment['CORE'] == 0) {} but I'm not sure where I would add this?

The config.bld file can be added directly to your project next to the other files (*.c,*.cfg). The RTSC tools will then use your config.bld file at build time.

CalvinC said:

Can I use that as the Build.platformTable[] and modify just the DDR2 sections in the config.bld?

Yes. You can specify your platform in the config.bld script as well. If you go this route you do not have to create a platform package using the platform wizard.

An example is shown below.

Build.platformTable["myPlatform"] = {
    deviceName: "TMS320C6486",
    catalogName: "ti.catalog.c6000",
    clockRate: 600,
    externalMemoryMap: [
        ["DDR2", {
            name: "DDR2",
            base: 0x80000000,
            len:  0x00800000,
            space: "code/data"}
        ],
    ]
};

Regards

Amit

Sasha, Amit,

This seems to mimic what I'm doing in BIOS5.4. However, can XDC pick up the value of 'CORE' from a Windows environment variable? When I build all cores, I run a batch file that sets the Windows environment variable then calls the command line compile function:

@echo Build all MMA DSP Encoder cores

@set WS_DIR=C:\MyProjects\MMA\DSP\workspace

@set PRJ_DIR=%cd%

@pushd %TI_DIR%

@cd eclipse

@for /L %%C in (1,1,5) do (

echo Building Core %%C

set "CORENUM=%%C"

jre\bin\java -jar startup.jar -data "%WS_DIR%" -application com.ti.ccstudio.apps.projectBuild -ccs.projects mma_dsp_encoder -ccs.configuration %1

copy /y %PRJ_DIR%\%1\mma_dsp_encoder.out %PRJ_DIR%\core%%C.out

copy /y %PRJ_DIR%\%1\mma_dsp_encoder.map %PRJ_DIR%\core%%C.map

)

@popd

The other option would be to pass a "-DCORENUM=1" like argument to the commandline compile function if that is possible. Since it takes quite a while to compile the project 5 times (10+ minutes) I'm anxious to be able to use a script one way or another.

Last, I'm assuming that if I specify my base (unmodified) custom RTS platform in the CCS Build Properties | RTSC, it will find my modified config.bld without having to include it in my project. However, if I link config.bld part into my project, what do I use as the RTSC Platform? Still use the base (unmodified) platform or does it matter since it gets re-assigned in the config.bld? If it doesn't matter then instead of having a repository of custom platforms, can I just put my config.bld file in my project directory?

Sorry for all the detail questions, just trying to grasp the finer points since I'm doing something out of the norm. Thanks again,

Calvin

Amit, Sasha,

Sounds like I picked a good time to finally start using SysBios. CCS 4.2 seems to have resolved a variety of issues. Many thanks for all of your insights. I think now I just have to try out your suggestions and see what works best.

Thanks again,

Calvin

Amit, Sasha,

I'm not getting the expected results. No matter what I put in the config.bld file, the map file shows DDR2 still at the platform package specification.

I created a custom platform called "mma_dsp" with the actuall physical memory locations (DDR2 at 0xE0000000). I have this platform selected in CCS Build | RTSC | RTSC Platform (have to have some here or can't accept the page).

I have a simple config.bld file to change the DDR2 map (reduce size and place in specific region):

Build.platformTable["mma_dsp"] = {
   externalMemoryMap: [
      ["DDR2",
         {
         name: " DDR2 ",
         base: 0xe6000000,
         len: 0x02000000,
        space: "code/data",
        }
    ]
  ]
};

However, everything linked to DDR2 is placed at 0xE0000000 instead of 0xE6000000. What am I missing? Attached in the generated *.zip file for the platform.8304.mma_dsp.zip

Also, I have .cinit and .pinit listed in my link.cmd file. In the *.map file there are multiple sections name ".cinit" and they are located at differing block of memory (some in DDR where I specifiy and some in LL2RAM. How do I reign in SysBIOS to actully put stuff where I request?

Thanks,

Calvin

I figured out the section map issue. I added a Program.sectMap[".cinit"] to my *.cfg file and not I get the epxected results.

Now I just need to understand how to make the config.bld script work.

Thanks,

Calvin

Hi Calvin,

You need to define an instance of a generic platform in your config.bld script. If you are interested in the theory you can take a look at http://rtsc.eclipse.org/docs-tip/Using_Targets_and_Platforms#Using_the_Generic_Platform.

Your config.bld script should look something like this

Build.platformTable["ti.platforms.generic:mma_dsp"] = {

    deviceName: "TMS320CTCI6486",

    catalogName: "ti.catalog.c6000",

    clockRate: 500,

    externalMemoryMap: [

        ["DDR2", {

            name: "DDR2",

            base: 0xe6000000,

            len:  0x02000000,

            space: "code/data"}

        ],

    ]

};

var C64P = xdc.useModule('ti.targets.C64P');

C64P.rootDir = "C:/Program Files/Texas Instruments/ccs4_2/ccsv4/tools/compiler/c6000";

C64P.platform = "ti.platforms.generic:mma_dsp";

Build.targets = [C64P];

Now you have a platform instance named ti.platforms.generic:mma_dsp defined in your system with your custom memory map.

In the RTSC project properties page you should refer to this platform instance in the text box labeled RTSC Platform:. Take a look at the screenshot below.

Now your application is all setup to use the custom platform defined by you.

         name            origin    length      used     unused   attr    fill

----------------------  --------  ---------  --------  --------  ----  --------

  SL2RAM                00200000   000c0000  00000000  000c0000  RW X

  LL2RAM                00800000   00098000  00000000  00098000  RW X

  DDR2                  e6000000   02000000  00017cee  01fe8312  RWIX

Note that since you are defining your platform in the "config.bld" file there is no need to use the platform wizard to create a platform package.

Regards

Amit

Amit,

Ok, that solved the DDR2 issue, but now my custom LL2RAM (for C6486 boot area @0x0080000), SL2RAM and cache settings from my custom platform are no longer available. What members do I use to modify those? customMemoryMap?

-Calvin 

Amit,

Now I'm feeling dangerous. Despite incorrect/misleading information in the doc files, I've got a config.bld file that works (see below). The only remaining question is configuring the cache. Will including "ti.sysbio.family.c64p.Cache" module in my *.cfg configure it correctly? Also, how important is C64P.rootDir and does it get re-set correctly during compile. Since I might change versions of compilers at any time, it is undesirable to have that kind on information in a user file. That should be generated by the tools at compile time.

Thanks fro your help!

Calvin

var core = Packages.java.lang.System.getenv("CORENUM"); /* get the system environment variable to select Core to compile for */
var ddr2_base = 0xe6000000; /* default to core 1 */

if (core == 0) {
  ddr2_base = 0xe0000000;
}
else if (core == 1) {
  ddr2_base = 0xe6000000;
}
else if (core == 2) {
  ddr2_base = 0xe8000000;
}
else if (core == 3) {
  ddr2_base = 0xea000000;
}
else if (core == 4) {
  ddr2_base = 0xec000000;
}
else if (core == 5) {
  ddr2_base = 0xee000000;
}


print("\nConfiguring for Core =", core);
print("DDR2 base address =", ddr2_base);

Build.platformTable["ti.platforms.generic:mma_dsp"] = {
   deviceName: "TMS320CTCI6486",
   catalogName: "ti.catalog.c6000",
   clockRate: 625,
   customMemoryMap: [
       ["L1PSRAM", {name: "L1PSRAM", base: 0xE00000, len: 0x008000, space: "code",access: "RWX"}],
       ["L1DSRAM", {name: "L1DSRAM", base: 0xF00000, len: 0x008000, space: "data",access: "RW"}],
       ["LL2RAM", {name: "LL2RAM", base: 0x00800020, len: 0x00097fe0, space: "code/data",access: "RWX"}],
       ["SL2RAM", {name: "SL2RAM", base: 0x00210000, len: 0x000B0000, space: "code/data",access: "RWX"}],
       ["LL2RAM_BOOT", {name: "LL2RAM_BOOT", base: 0x00800000, len: 0x00000020, space: "code/data",access: "RWX"}],
       ["DDR2", {name: "DDR2", base: ddr2_base, len: 0x02000000, space: "code/data",access: "RWX"}],
   ],
/* SL2RAM from 0x00200000 to 0x0020FFFF is reserved for manually allocated shared data structures */

   codeMemory: "LL2RAM",
   dataMemory: "LL2RAM",
   stackMemory: "LL2RAM",

   sectMap:[
      [".cinit", "DDR2"],
      [".pinit", "DDR2"], 
   ],
};


var C64P = xdc.useModule('ti.targets.C64P');
C64P.rootDir = "C:/Program Files/Texas Instruments/ccs4_2/ccsv4/tools/compiler/c6000";
C64P.platform = "ti.platforms.generic:mma_dsp";
Build.targets = [C64P];

Hi Calvin,

You can configure the cache by setting the l1DMode,l1PMode and l2Mode configuration parameters in your platform instance creation.

To set L1D and L1P cache to 32k and L2 to 64K you will need to have the following platform definition.

Build.platformTable["ti.platforms.generic:mma_dsp"] = {

    deviceName: "TMS320CTCI6486",

    catalogName: "ti.catalog.c6000",

    clockRate: 500,

    externalMemoryMap: [

        ["DDR2", {

            name: "DDR2",

            base: 0xe6000000,

            len:  0x02000000,

            space: "code/data"}

        ],

    ],

    l1DMode:"32k",

    l1PMode:"32k",

    l2Mode:"64k"

};

The BIOS cache module will inspect these parameters and program the cache registers accordingly at startup. You do not have to configure the cache manually.

CalvinC said:

Also, how important is C64P.rootDir

The rootDir parameter of the target contains the location of the toolchain. You can use an environment variable here as well, which can then be controlled by your build flow.

Regards

Amit

Amit,

Great! Now the config.bld does have everything.

As far as rootDir, since I specifiy which version of CGT I want to use inside CCS4 Properties, isn't there a way to link C64P.rootDir to that value (like a $(PROJECT...) type variable - given all the other automatically generated files and environment variables created by CCS/CGT)? Having to specify which tools to use in two different places is a "hard-to-find" bug waiting to happen.

Thanks,

Calvin

Calvin,

You are not required to specify the 'rootDir' parameter to the target in your 'config.bld' script when you are using the script inside a CCS4 managed make project.. XDCtools will pickup the version of the compiler from your project settings. I agree it makes sense to just specify the toolchain in one place - which is the project properties page. So just remove the statement initializing the 'rootDir' parameter of your target from your config.bld and you should be good to go.

Regards

Amit

Wonderful! Many thanks!

Calvin