Binary Nanostack build

[SeppoTakalo]

Description

Binary build of Nanostack with all configurations & toolchains.

Toolchains:

• ARMCC
• IAR
• GCC

Cores:

• Cortex-M0 (used also with M0+)
• Cortex-M3 (Used also with M4&M7)

Configurations:

• LOWPAN_BORDER_ROUTER
• LOWPAN_HOST
• LOWPAN_ROUTER
• NANOSTACK_FULL
• THREAD_BORDER_ROUTER
• THREAD_END_DEVICE
• THREAD_ROUTER

Low level FEATURE_IPV6 is removed because of #2784
Replaced with feature/net/nanostack that contains all supporting module and glue layer between nanostack.
Binary release is git-subtree from https://github.com/ARMmbed/sal-stack-nanostack
In future, I will use git subtree pull to update it so no manual copy&pasting.

Status

READY

Migrations

Now applications should define one of the configurations in their mbed_app.json
Like this:

    "target_overrides": {
        "*": {
            "target.features_add": ["NANOSTACK_FULL", "COMMON_PAL"],
            "mbed-trace.enable": 1
        }

[SeppoTakalo]

CC: @kjbracey-arm @sg-

[sg-]

I'm wondering given that client isn't in the tree anymore if common_pal can also be reworked. @yogpan01 is there still a client dependency on this?

[kjbracey]

It remains a component shared by Nanostack and mbed Client. If either mbed Client or Nanostack is in use, it needs to be available.

So as Nanostack remains in tree, it must remain in.

Only rework I could see is pulling both Nanostack and the support code out of tree like Client.

[SeppoTakalo]

Arg.. There is now problem I did not spot.
Now that we moved nanostack related module out of FEATURE_IPV6 there is now compile time dependency to FEATURE_COMMON_PAL

How should we solve this?
I would propose that we also move the FEATURE_COMMON_PAL out as it is collection of support libraries that currently only Nanostack uses, but they are general enough for common use.

[SeppoTakalo]

I cannot any sensible workarounds for this. We need to raise the priority of original issue and allow nested features.
Otherwise we cannot do the binary release as we designed.

[sg-]

Why does this not work??

{
   features_add:[FEATURE_COMMON_PAL, FEATURE_COMMON_NANOSTACK, FEATURE_NS_6LP_HOST]
}

nanostack
    ○ FEATURE_COMMON_NANOSTACK
        § NanostackInterface and headers
    ○ FEATURE_NS_6LP_HOST
        § TARGET_CORTEX_Mx
            □ TOOLCHAIN_GCC
            □ TOOLCHAIN_ARM
            □ TOOLCHAIN_IAR
    ○ FEATURE_NS_6LP_ROUTER
    ○ FEATURE_NS_6LP_BORDER_ROUTER
    ○ FEATURE_NS_THREAD_HOST
    ○ FEATURE_NS_THREAD_ROUTER
    ○ FEATURE_NS_THREAD_BORDER_ROUTER
    ○ FEATURE_NS_FULL

[SeppoTakalo]

That would force us to split repositories and manually move header out from sal-stack-nanostack

FEATURE_NANOSTACK
           +
           +-----> sal-stack-nanostack
           |                  +
           |                  +--> headers
           |                  |
           |                  +--> FEATURE_LOWPAN_ROUTER
           |
           +-----> mbed-mesh-api

Now if we do that. How would I be able to replace sal-stack-nanostack with the source repository?

The idea behind this is that those same FEATURE_XXX would appear in the source tree and allows us to pick the proper configuration file when using sources with the build.

If we split repositories, we also need to implement second mechanism for selecting configuration when sources are attached instead of binary modules.

It would also require manual steps when sources are attached. instead of rm -r sal-stack-nanostack; ln -s <your source path>

Also, maybe the biggest thing is that I cannot use git subtree merge anymore when bringing in the changes.

[SeppoTakalo]

@hasnainvirk Can you start manual testing of these binaries?

[sg-]

/morph test

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1000

All builds and test passed!

[SeppoTakalo]

6LoWPAN now tested.
Looking OK.

mbed-os-example-mesh-minimal

Configuration	Compiler	Binary size(kB)
NANOSTACK_FULL	GCC	568
LOWPAN_ROUTER	GCC	254
LOWPAN_HOST	GCC	205
NANOSTACK_FULL	ARM	517
LOWPAN_ROUTER	ARM	203
LOWPAN_HOST	ARM	157

I'm not expecting surprises from Thread configs so from our point of view, this should be ready for merge.

[mazimkhan]

retest uvisor