MBED_ROM_START and friends unavailable on Mbed CLI2

[ccli8]

Description

On Mbed CLI, the following symbols are generated and passed to compiler, linker, or both:

mbed compile -m NUMAKER_IOT_M487 -t ARM

BUILD/NUMAKER_IOT_M487/ARM/.profile.c:

{
    "flags": [
        ......
        "-DMBED_RAM_SIZE=0x28000",
        "-DMBED_RAM_START=0x20000000",
        "-DMBED_ROM_SIZE=0x80000",
        "-DMBED_ROM_START=0x0",
        ......

BUILD/NUMAKER_IOT_M487/ARM/.profile.ld:

{
    "flags": [
        ......
        "--predefine=\"-DMBED_BOOT_STACK_SIZE=1024\"",
        "--predefine=\"-DMBED_RAM_SIZE=0x28000\"",
        "--predefine=\"-DMBED_RAM_START=0x20000000\"",
        "--predefine=\"-DMBED_ROM_SIZE=0x80000\"",
        "--predefine=\"-DMBED_ROM_START=0x0\"",
        ......

But on Mbed CLI2, they are unavailable in cmake_build/NUMAKER_IOT_M487/develop/ARM/mbed_config.cmake or elsewhere.

mbed-tools compile -m NUMAKER_IOT_M487 -t ARM

Issue request type

• Enhancement
• Bug

Mbed/Tool version

mbed-os: 6.8.0
mbed-cli: 1.10.5
mbed-tools:: 7.2.1

[jeromecoutant]

I think idea is to remove the dependency with tools/arm_pack_manager/index.json file which is not really maintained...?

[Patater]

What are these files used for?

Is .profile.c is a json file, even though it ends in .c?

What is the high-level use case here?

[Patater]

This may be a duplicate of #156

[ccli8]

The -DMBED_ROM_START=0x0 and friends defined in .profile-c/.profile-cxx are passed to C/C++ source files for preprocess. And the --predefine=\"-DMBED_RAM_START=0x20000000\" and friends defined in .profile-ld are passed to linker file (.sct for ARM toolchain) for link-time preprocess.

The MBED_ROM_START and friends are not necessarily related to bootloader (#156). They are derived from target configuration:
https://github.com/ARMmbed/mbed-os/blob/0e89f9d6d9cab31dde3db801cd8f4516f94a7279/targets/targets.json#L2925-L2928

MBED_BOOT_STACK_SIZE is derived from:
https://github.com/ARMmbed/mbed-os/blob/0e89f9d6d9cab31dde3db801cd8f4516f94a7279/targets/targets.json#L60-L63
https://github.com/ARMmbed/mbed-os/blob/0e89f9d6d9cab31dde3db801cd8f4516f94a7279/cmsis/device/rtos/mbed_lib.json#L63-L66
On Mbed CLI, it is generated in:
https://github.com/ARMmbed/mbed-os/blob/0e89f9d6d9cab31dde3db801cd8f4516f94a7279/tools/toolchains/mbed_toolchain.py#L968-L974

[Patater]

What do C/C++ source files use these for? I can understand wanting to customize the linkerscript, but beyond that, I am currently unclear how these variables are useful.

We can implement passing them along, but it'd be good to understand why and where they are needed.

[ccli8]

Just list one known use case. On mbed-os-5.15, on Nuvoton's M2351/M2354 TrustZone non-PSA targets, MBED_ROM_START/MBED_ROM_SIZE are used to define valid Flash IAP range due to their configurable:

https://github.com/ARMmbed/mbed-os/blob/1faaabb6fad9ce7a3b31553718f8acdb04330b40/targets/TARGET_NUVOTON/TARGET_M2354/flash_api.c#L85-L90

https://github.com/ARMmbed/mbed-os/blob/1faaabb6fad9ce7a3b31553718f8acdb04330b40/targets/TARGET_NUVOTON/TARGET_M2354/flash_api.c#L101-L106

On Mbed OS 6, M2351/M2354 are removed and I am not clear if they are used elsewhere. Or they can be used like above use case.

[LDong-Arm]

@ccli8 @Patater Another option to get application start address & size is to reference regions defined in linker script. Example: https://github.com/ARMmbed/mbed-os/blob/master/drivers/include/drivers/FlashIAP.h#L35-L50

But if #156 does rely on MBED_*** then it makes sense to define them anyway.

[ccli8]

In use case like ARMv8M TF-M/Mbed integration, ROM/RAM memory spec are defined in TF-M. This information must pass to Mbed from TF-M via external means like target.mbed_rom_start and friends.

[Patater]

@ccli8 For TF-M, could we use region_defs.h for the necessary defines? See MUSCA B1's region_defs.h for example.