Bare-metal profile

[theotherjimmy]

Description

This pull request provides the "bare-metal profile" that allows for mbed OS
to be built "bare-metal" or without an rtos. Requirinng the bare-metal
library limits the code built into mbed OS to the hal, drivers, and
platform.

The following table is the difference when using bare metal with release profile
on a simplified blinky example.

Module	.text	.data	.bss
[fill]	111(-33)	8(+4)	2327(+206)
[lib]/c.a	17815(+0)	2472(+0)	89(+0)
[lib]/gcc.a	3112(+0)	0(+0)	0(+0)
[lib]/misc	204(+0)	4(+0)	28(+0)
main.o	56(+0)	0(+0)	4(+0)
mbed-os/cmsis	1033(+0)	0(+0)	0(+0)
mbed-os/components	0(-56)	0(+0)	0(+0)
mbed-os/drivers	80(+18)	0(+0)	0(+0)
mbed-os/features	0(-42)	0(+0)	0(-184)
mbed-os/hal	1396(-68)	4(-4)	66(-64)
mbed-os/platform	1961(-550)	260(+0)	201(-56)
mbed-os/rtos	0(-6929)	0(-168)	0(-5973)
mbed-os/targets	5232(-788)	12(+0)	381(-1)
Subtotals	31000(-8448)	2760(-168)	3096(-6072)

Total Static RAM memory (data + bss): 5856(-6240) bytes
Total Flash memory (text + data): 33760(-8616) bytes

Further, build time is reduced from 25sec to 8sec on my desktop and
1m22s to 13s on my mid-2014 mac book pro.

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[x] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

?

Release Notes

Mbed OS may now be built without the rtos by creating an mbed_app.json with
the following contents:

{
    "requires": ["bare-metal"]
}

[ciarmcom]

@theotherjimmy, thank you for your changes.
@ARMmbed/mbed-os-maintainers please review.

[theotherjimmy]

I filled out the required sections to my satisfaction. Removing do not merge.

[0xc0170]

Looks simple !

into mbed OS to the hal, drivers, and platform.

How HAL gets in? I see requires only for platform and drivers. I could not find anything in these 2 folders that would pull in HAL (.json file requires HAL) ?

We got build profiles in the tools, this is in the components? What else is coming there? Should Readme be there describing the profiles ?

[theotherjimmy]

@0xc0170 in order:

How HAL gets in? I see requires only for platform and drivers. I could not find anything in these 2 folders that would pull in HAL (.json file requires HAL) ?

It has no mbed_lib.json, so it's pulled in with the same rules as the targets directory and the user's application: No lib = pulled in.

We got build profiles in the tools, this is in the components?

Suggest a better location if you prefer.

What else is coming there? Should Readme be there describing the profiles ?

Nothing else is planned. Perhaps a Readme would be fine.

[bulislaw]

This PR is at risk of missing 5.12 release as it's marked as "needs: review". Code freeze is coming! On Friday 1st. Please review the changes ASAP.

@0xc0170 @bridadan @SenRamakri

[cmonr]

CI started whilst reviews are completed

[cmonr]

CI started for now to see where the PR stands.
Re-reviews still needed.

Ok, maybe it's time for sleep. Duplicate job stopped.

[bulislaw]

Please don't use "components" directory - these aren't the droids you are looking for (I'm so regretting allowing it to be created in the first place). The initial idea was to keep "drivers" for external HW components there, but now it became a go to directory for everything. Could we put the build profiles under tools? As it's a part of the build system. Also we need design document, but I won't block the merging based on that. Also changes to the Handbook and maybe blog post (?) to introduce the concept @SenRamakri

[mbed-ci]

Test run: SUCCESS

Summary: 12 of 12 test jobs passed
Build number : 1
Build artifacts

[theotherjimmy]

@bulislaw They can't go under tools, as no device-related code is under tools, and it's ignored, and it's data, not a tool.

[theotherjimmy]

As it's a part of the build system

This is not part of the build system. It's data, and I it's designed that way so that we don't have to worry about breaking changes or needing to update the online compiler for changes to the "build profile" (I still don't like calling it that, as it's neither a build nor a profile)

[theotherjimmy]

The initial idea was to keep "drivers" for external HW components there, but now it became a go to directory for everything.

Perhaps that intention needs to be documented.

[theotherjimmy]

Also changes to the Handbook and maybe blog post (?) to introduce the concept

What concept?

[theotherjimmy]

@bulislaw Please suggest another location (other than tools; this is not a tool, and tools is not scaned so it would not work) for this library.

[bulislaw]

This 4 lines represent bigger concept, corresponding tools changes are more than 4 lines I'm sure. The idea of build profiles deserves a design doc (it may be it was introduced with other PR).

(I still don't like calling it that, as it's neither a build nor a profile)

Actually the name needs to be changed as build profiles are "debug", "devel" and "release". Build variants? Scan profiles?

This is not part of the build system. It's data, and I it's designed that way so that we don't have to worry about breaking changes or needing to update the online compiler for changes to the "build profile"

How about build profile (eg debug) definitions? Isn't that data as well? I still think tools directory is the only logical place. If we need to work around the online compiler, I'd rather stuff it in platform than components.

[theotherjimmy]

@bulislaw

Build variants? Scan profiles?

Scan profiles was suggested during design. It's more of a library set than anything else. We can call them scan profiles; I'm not going to bikeshed further on this topic in this PR. Instead, I'm going to remove the directory from the path.

How about build profile (eg debug) definitions? Isn't that data as well?

Yes it is, and a user can add their own and pass them in. These may be in the tools dir, as they are not scanned. That's the big deal here: bare-meta is a library, and like all other libraries it must be scanned.

I still think tools directory is the only logical place.

The tools directory is not scanned and therefore cannot conntain a library.

I'd rather stuff it in platform than components.

I'll move it to platform and It'll be platform/bare_metal. Does that sound reasonable?

Changes addressed. Please re-review.

[cmonr]

CI started

[mbed-ci]

Test run: FAILED

Summary: 1 of 8 test jobs failed
Build number : 2
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_build-ARM

[cmonr]

Info: A CI config issue appears to be affecting NUMAKER_PFM_M2351 builds. Please ignore build errors against the target for now.

Other build failures should still be investigated, if any. Will restart CI when appropriate.

[bulislaw]

Looks good for now, we may need to rethink that later (if we add more profiles, we'll need an uber directory in platform to keep it tidy).

[0xc0170]

CI restarted

[theotherjimmy]

@bulislaw Agreed, having this in an "uber-directory" is a bridge we can cross when we get there.

[mbed-ci]

Test run: FAILED

Summary: 1 of 13 test jobs failed
Build number : 3
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_exporter

[alekla01]

Ci restarted (iar8 exporter issue will be resolved separately).

[0Grit]

@theotherjimmy It's probably obvious from your description but does this library/profile leave out eventQueues?

Maybe eventQueues are considered to be in rtos territory, but no matter how simple the application I'd never go bare metal without an event loop.

[cmonr]

@loverdeg-ep You bring up an interesting point. Since we'd like to bring this in before code freeze, I'd propose opening an issue for the question, linking to this PR.

I personally know of many simple use-cases where an RTOS is overkill, and even an Event Queue might not be needed.

[0Grit]

@cmonr Not trying to stop the press, just vacuuming info.