NDK - How to get rid of non-used features ?

Clement FR

Other Parts Discussed in Thread: OMAPL138

Hello everyone,

Target is C6678 with SYSBIOS6.
In our application we'll have to use only UDP and RAW Ethernet communication.
We don't need http, telnet, dhcp, IPv6 and other things present in the NDK package.

We want to minimize the NDK footprint and of course maximize the UDP/RAW Eth performance.

I'd like to know how to disable completely all the features we don't use.

Is building SYS/BIOS as custom enough ?
Do we have to rebuild the NDK ?

Any tips to improve UDP and Raw Eth performance will be greatly appreciated too.

Thank you
Clément

over 12 years ago

0 Steven Connell over 12 years ago

TI__Mastermind 45025 points

Which version of the NDK are you using?

If you have a new enough version, some of this work is already done for you in the 'netctrl' package. You might try linking the library "netctrl_min" (ti/ndk/netctrl/lib) which enables the app to run as a DHCP client, but disables Telnet server, Http server, NAT server, DHCP server, and DNS server.

If you prefer a different combination of these features, then you must rebuild the netctrl library. This is done with some defines that should be passed as compiler options when rebuilding the netctrl package:

_NDK_EXTERN_CONFIG // define during build in order to override with below settings

// define these to 1 or 0 to enable/disable:

- NETSRV_ENABLE_TELNET
- NETSRV_ENABLE_HTTP
- NETSRV_ENABLE_NAT
- NETSRV_ENABLE_DHCPCLIENT
- NETSRV_ENABLE_DHCPSERVER
- NETSRV_ENABLE_DNSSERVER

You can see an example of how to use these defines as well as further details in the file ti/ndk/netctrl/package.bld.

Steve

0 Clement FR over 12 years ago in reply to Steven Connell

Genius 4750 points

Thank you Steve,

ndk_2_21_01_38
bios_6_33_06_50
xdctools_3_23_04_60

We looked at the memory map + generated linker.cmd and noticed that we use the standard netcrl library.

In the documentation (NDK UG) it says that it chooses automatically the netcrl lib. It doesn't explain how to force it to use another one.
How can we link the netcrl_min library ?

Also in ndk_2_21_01_38\packages\ti\ndk\netctrl\lib there is both
netctrl_min.ae66
and netctrl_min_ipv4.ae66

We should use netctrl_min_ipv4.ae66 for best performance/minimum footprint right ? (we don't use IPv6).

We'll look later on how to rebuild the netctrl lib with the enable/disable #define.

Regards,
Clément

0 Steven Connell over 12 years ago in reply to Clement FR

TI__Mastermind 45025 points

Clement,

You can add the following code to your BIOS configuration file (*.cfg) to get IPv4 versions of libraries and minimal other minimal libraries:

var Global = xdc.useModule('ti.ndk.config.Global');
Global.IPv6 = false;
Global.stackLibType = Global.MIN;

However, this won't affect the netctrl library, unfortunately...

Clement Mesnier said:
In the documentation (NDK UG) it says that it chooses automatically the netcrl lib. It doesn't explain how to force it to use another one.

Can you check a setting in your BIOS configuration file (*.cfg) for me? I would like to know what the value of the following code is for your configuration:

Global.enableCodeGeneration = {true or false?};

Do you see these settings in your *.cfg? Is the setting for enableCodeGeneration true or false?

If it is true, then it should be easy to get the minimal netctrl library. You need to make sure that you are *not using* the Telnet, Http, DhcpServer, Dns or Nat modules in your configuration. This is how the logic determines to link in a minimal netctrl or not.

But if this setting is false, then the solution is a bit trickier. With that setting to false, it means that the NDK stack thread code is part of you application (i.e. it's not being generated automatically for you).

So if it's false, you have 2 options that I can see:

1. change it to be true and use the NDK generated stack task. You would need to remove the "non generated one" that's in your app (it's probably called ''StackTest"), since setting enableCodeGeneration to true will cause it to be autogenerated. There may be some other hurdles to overcome, depending on the complexity of your 'StackTest' task.

2. Modify the JavaScript file that contains the logic for library selection.

# 2 is a hack for sure, but would probably be the easiest work around for you. The library selection logic is found in the following file in your NDK installation:

ndk_2_21_02_43\packages\ti\ndk\config\package.xs

I think you are probably hitting the following lines, and can change them as shown in the comment below:

    else if (Telnet.$used || Http.$used || !(Global.enableCodeGeneration)) {
        /*
         * If user wants Telnet or Http, but not DHCP/DNS/NAT servers, then use
         * "standard" lib.
         *
         * Also must choose standard netctrl lib for legacy applications (in
         * which code generation is disabled)
         */
        netctrlLib = "netctrl"; // <-- change this to be "netctrl_min"
    }

Once you have the above, you should clean and rebuild your project. You can check the *.xdl file as you've already been doing to ensure correctness.

Steve

0 Clement FR over 12 years ago in reply to Steven Connell

Genius 4750 points

Steve,

Thank you for the detailled reply, it's highly informative.

Unfortunately we started with the NDK example which have :
/*
** This allows the heart beat (poll function) to be created but does not generate the stack threads
**
** Look in the cdoc (help files) to see what CfgAddEntry items can be configured. We tell it NOT
** to create any stack threads (services) as we configure those ourselves in our Main Task
** thread hpdspuaStart.
*/
Global.enableCodeGeneration = false;

We'll try your suggestion n°1 before hacking the package.

My question is : StackTest is quite large and configures a lot of things.
If we remove it does it mean that we have to configure things elsewhere ?

For example inside StackTest we use
rc = 8000;
CfgAddEntry( hCfg, CFGTAG_IP, CFGITEM_IP_SOCKUDPRXLIMIT, CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

it means that we should do it in the CFG ?

That brings me to another question :

In the documentation (NDK user guides) it is written many that we shouldn't mix static cfg configuration of the NDK with dynamic configuration.
Yet in the NDK hello world example there is both static configuration
var Global = xdc.useModule('ti.ndk.config.Global');
Global.something = somethingelse;

and dynamic configuration
hCfg = CfgNew();
CfgAddEntry( hCfg, CFGTAG_ROUTE, 0, 0, sizeof(CI_ROUTE), (UINT8 *)&RT, 0 );

That's really confusing me, can you explain to me why not all is done in the CFG file ?

Regards,
Clément

0 Steven Connell over 12 years ago in reply to Clement FR

TI__Mastermind 45025 points

Clement,

Clement Mesnier said:
My question is : StackTest is quite large and configures a lot of things.
If we remove it does it mean that we have to configure things elsewhere ?
...

it means that we should do it in the CFG ?

Yes. The *.cfg file provides an alternative way to configure the NDK. In fact, it is only a facade to the run time configuration APIs that you are seeing in your existing StackTest() function.

All of the configuration settings that can be made via the *.cfg file (GUI or text edit) can also be done in the run time configuration. The configuration settings are used to generate the C configuration code.

If you have a couple of hours to spare, I would suggest trying some experimenting that I think will be very helpful for you to get a better understanding of this.

First, I would suggest to take a look at the client or helloWorld example that's for a different hardware platform - the omapL138 - which is available in a separate product called the NSP (it's a small download). The client and helloworld examples in that product are designed to fully use the NDK's GUI configuration (and code generation). You can look import these examples into a new workspace and build them, then see how the generated code changes based on the settings you change in the GUI. (The generated code will be in a very large C file called "helloworld_evmc6678l/Debug/configPkg/package/cfg/helloWorld_p674.c" (look for the function called "ti_ndk_config_Global_stackThread")

While doing that, I would also suggest that you use section 1.7 of the NDK User's Guide (spru523h.pdf). Reading this section while experimenting with one of those examples will help to explain the NDK configuration and how to use the GUI works.

So, to summarize:

1. Download the omapL138 NSP here. The latest version, 1.10.02.09 is meant for CCSv5.4. Earlier versions support earlier CCS versions; make sure to get the one that corresponds to the CCS version you are using.

Again, this NSP is just for experimental purposes relating to the NDK GUI configuration; it's a product for a different hardware platform and so is not compatible for use with your 6678.

2. Create a new CCS workspace for this experimenting, then shut down CCS.

3. Install the NSP

4. Start CCS, allow it to detect the new NSP product, restart workbench when prompted.

5. Once CCS starts again, import the existing NSP example (client or helloWorld). You can find details on how to import them in the NSP release notes

At this point, you can build the example and experiment with the configuration. Use section 1.7 of the user's guide for reference.

If you want to see the results of the changes/settings of the GUI configuration file, have a look at the generated file and function ti_ndk_config_Global_stackThread.

You might also try comparing the configuration code of that function with the StackTest() function that's in your 6678 application, to see the similarities.

I think once you have done this experimenting, you will have a better understanding of how to apply the settings of your 6678 app's StackTest() function into the GUI, so that you can remove it and rely on the generated *_stackThread function.

Steve

0 Clement FR over 12 years ago in reply to Steven Connell

Genius 4750 points

Steve,

Thank for your long and detailled answer.

I'm about to go on vacation so time is missing to experiment with the NSP right now.

So we are putting this on hold. I'll come back on this subject later.

Regards,
Clément

0 Steven Connell over 12 years ago in reply to Clement FR

TI__Mastermind 45025 points

Clement,

Since you are short on time, you might try option #2 that I mentioned above:

2. Modify the JavaScript file that contains the logic for library selection.

It's certainly OK to try this and it's a very easy thing to do. Just make sure that you back up the package.xs file before modifying it (I would even suggest making a back up of the entire NDK before attempting to modify anything in it, just to be safe). This would let you link in the minimal library that you want and allow you to check out the results of that, without the big hassle of converting your StackTest() thread to the new config and resulting generated stackThread() function.

I would say the only danger in doing that is you might forget about the change that you have made while on vacation :)

Steve

0 Clement FR over 12 years ago in reply to Steven Connell

Genius 4750 points

Steve,

I discussed today with my colleague that is also working on the NDK.

He saw the thread and managed to port what was in the StackThread function to the cfg.

He also rebuilt the NDK to go further than the netctrl min library (disabling the DHCP server for example).

It's all good now.

Clement

Processors

Processors forum

NDK - How to get rid of non-used features ?