Fix memory reservation for Softdevice in NRF52_DK

[JammuKekkonen]

Description

The current system checks mbed app start trying to check whether softdevice is in use or not during linking. This doesn't work when bootloader is in use, so softdevice existence needs to be explicitly injected to linker scripts.

Pull request type

[X] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change

[JammuKekkonen]

@yogpan01

[yogpan01]

@bulislaw can you please review, if this is good enough. We needed to free the remaining RAM for our usage when not using SOFT DEVICE but have our own bootloader as well.
@0xc0170 if possible we want this to go in mbed-os-5.10-rc1

[adbridge]

@yogpan01 Code freeze for RC1 was last Friday so unless this is a blocker it won't make it in now. If this is critical for 5.10 please discuss with @ChiefBureaucraticOfficer as to whether we consider this for RC2.

[yogpan01]

@ChiefBureaucraticOfficer This is blocker for us to support NRF52 on Client Lite. Can you please take this in for 5.10 release.

[ghost]

@yogpan01 - Do you have a timeline for the need? This appears to be a point fix, which can go in to fortnightly patch releases. Should it be extremely time sensitive we can pull it in for RC2. Please advise on criticality and downstream impacts.

[0xc0170]

With this change, MBED_APP_START is being removed, thus what specifies that there is app moved (bootlader in) ? I would expect to have a condition to check MBED_APP_START and then softdevice might change the values or am I missing something?

[yogpan01]

In my understanding the original code made assumption that if your MBED_APP_START is 0 it implied that you are using SoftDevice, which is blocking the case where you don't have SoftDevice but have your own bootloader. This change makes the flow more logical.
If you have SoftDevice, we reserve RAM for you otherwise you get the complete RAM. There is no ambiguity in the interpretation now.

[yogpan01]

@ChiefBureaucraticOfficer We are fine if this can be taken into RC2 as well. Without this we cannot add support for NRF52 for Client Lite as this is one of the reference board we are planning to release in our next increment scheduled for next release, which is supposed to be ASAP.

[pan-]

This doesn't work when bootloader is in use, so softdevice existence needs to be explicitly injected to linker scripts.

Could you provide more explanation ? What are the bootloader requirements ?

[cmonr]

@yogpan01 Please answer @pan-'s question before we start CI.

[yogpan01]

@pan- We need to run cloud client on NRF52 board and we are not requiring Soft device. Cloud Client has a requirement that it comes with its own bootloader support so the app start address is not 0 but offset from bootloader region. With the current linker design of NRF52 layout its not possible to achieve this, since the assumption is that application without SoftDevice will always start from address 0, which is not the case, hence this change.

[0xc0170]

As long as bootloader and also soft device are all working

[pan-]

Approved the NRF52 changes. Need validation for the tooling part.

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 3029
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7971/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[mbed-ci]

Test : SUCCESS

Build number : 2800
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7971/2800

[mbed-ci]

Exporter Build : SUCCESS

Build number : 2646
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/7971/

[theotherjimmy]

I don't approve of part of these tools changes. Please don't merge tools things without my approval.

[theotherjimmy]

This is especially bad because It's super target specific, uses MACROS and CAN'T BE REMOVED without breaking compatibility with 5.10.x!