Silabs targets don't compile with blinky-baremetal

[MarceloSalazar]

Description of defect

Few Silabs targets fail to compile blinky-baremetal in Mbed OS 6

[mbed] Working path "D:\mbed\6.0-test\mbed-os-example-blinky-baremetal" (program)
WARNING: MBED_GCC_ARM_PATH set as environment variable but doesn't exist
Building project mbed-os-example-blinky-baremetal (EFM32GG11_STK3701, ARMC6)
Scan: mbed-os-example-blinky-baremetal
Link: mbed-os-example-blinky-baremetal
[Warning] @0,0: L3912W: Option 'legacyalign' is deprecated.
[Error] @0,0: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Base (referred from BUILD/EFM32GG11_STK3701/ARM/mbed-os/platform/source/mbed_sdk_boot.o).
[Error] @0,0: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Length (referred from BUILD/EFM32GG11_STK3701/ARM/mbed-os/platform/source/mbed_sdk_boot.o).
Warning: L3912W: Option 'legacyalign' is deprecated.
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Base (referred from BUILD/EFM32GG11_STK3701/ARM/mbed-os/platform/source/mbed_sdk_boot.o).
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Length (referred from BUILD/EFM32GG11_STK3701/ARM/mbed-os/platform/source/mbed_sdk_boot.o).
Finished: 0 information, 1 warning and 2 error messages.
[ERROR] Warning: L3912W: Option 'legacyalign' is deprecated.
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Base (referred from BUILD/EFM32GG11_STK3701/ARM/mbed-os/platform/source/mbed_sdk_boot.o).
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Length (referred from BUILD/EFM32GG11_STK3701/ARM/mbed-os/platform/source/mbed_sdk_boot.o).
Finished: 0 information, 1 warning and 2 error messages.

Target(s) affected by this defect ?

• EFM32GG_STK3700
• EFM32GG11_STK3701
• TB_SENSE_12

GCC and ARM Errors

Toolchain(s) (name and version) displaying this defect ?

Arm Compiler 6 and GCC 9

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.0.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed CLI 1.10.4

How is this defect reproduced ?

mbed import https://github.com/ARMmbed/mbed-os-example-blinky-baremetal
cd mbed-os-example-blinky
mbed compile -t <toolchain> -m <target>

@ARMmbed/team-silabs

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2721

[stevew817]

OK. This is due to us missing a heap declaration in the linker script. This works for RTOS due to the following in mbed_boot_arm_std.c:

#if !defined(HEAP_START)
// Heap here is considered starting after ZI ends to Stack start
extern uint32_t               Image$$RW_IRAM1$$ZI$$Limit[];
#define HEAP_START            Image$$RW_IRAM1$$ZI$$Limit
#define HEAP_SIZE             ((uint32_t)((uint32_t)Image$$ARM_LIB_STACK$$ZI$$Base - (uint32_t)HEAP_START))
#endif

Is there a reason why the same construct wasn't applied to bare-metal? I.e. if no heap is defined, assume heap stretches from end of zero-init through the stack limit?

[stevew817]

Additionally, GCC baremetal does work, since it declares the heap from end of ZI (end) through the start of stack (__HeapLimit):

    mbed_stack_isr_start = (unsigned char *) &__StackLimit;
    mbed_stack_isr_size = (uint32_t) &__StackTop - (uint32_t) &__StackLimit;
    mbed_heap_start = (unsigned char *) &__end__;
    mbed_heap_size = (uint32_t) &__HeapLimit - (uint32_t) &__end__;

From compiling blinky-baremetal with GCC:

Elf2Bin: mbed-os-example-blinky-baremetal
| Module           |         .text |     .data |      .bss |
|------------------|---------------|-----------|-----------|
| [fill]           |       46(+46) | 344(+344) |   28(+28) |
| [lib]/c_nano.a   |   2382(+2382) | 100(+100) |   12(+12) |
| [lib]/gcc.a      |     768(+768) |     0(+0) |     0(+0) |
| [lib]/misc       |     180(+180) |     0(+0) |   28(+28) |
| [lib]/nosys.a    |       16(+16) |     0(+0) |     0(+0) |
| main.o           |       72(+72) |     0(+0) |     4(+4) |
| mbed-os/drivers  |       80(+80) |     0(+0) |     0(+0) |
| mbed-os/hal      |   1534(+1534) |     8(+8) | 131(+131) |
| mbed-os/platform |   4808(+4808) |     4(+4) | 298(+298) |
| mbed-os/targets  | 11846(+11846) |   24(+24) | 451(+451) |
| Subtotals        | 21732(+21732) | 480(+480) | 952(+952) |
Total Static RAM memory (data + bss): 1432(+1432) bytes
Total Flash memory (text + data): 22212(+22212) bytes

[stevew817]

This is a requirement/behavioral change on mbed OS, and I'd like to see a solution which brings the memory maps more in-line with each other, and not introduce an even wider gap @MarceloSalazar @ARMmbed/mbed-os-core

[0xc0170]

Thanks @stevew817 for details.

Is there a reason why the same construct wasn't applied to bare-metal? I.e. if no heap is defined, assume heap stretches from end of zero-init through the stack limit?

Looking at the history, this commit brings the change 3e3af70#diff-69c41b8becb0d25b48320173a11f0b82. Our memory model does not specify any difference between bare metal or full build (https://os.mbed.com/docs/mbed-os/latest/apis/memory-model.html). They should be equal, this seems to be a bug in the implementation.

We will review

[evedon]

OK. This is due to us missing a heap declaration in the linker script. This works for RTOS due to the following in mbed_boot_arm_std.c:

#if !defined(HEAP_START)
// Heap here is considered starting after ZI ends to Stack start
extern uint32_t               Image$$RW_IRAM1$$ZI$$Limit[];
#define HEAP_START            Image$$RW_IRAM1$$ZI$$Limit
#define HEAP_SIZE             ((uint32_t)((uint32_t)Image$$ARM_LIB_STACK$$ZI$$Base - (uint32_t)HEAP_START))
#endif

Is there a reason why the same construct wasn't applied to bare-metal? I.e. if no heap is defined, assume heap stretches from end of zero-init through the stack limit?

The same construct cannot be applied to bare metal because bare metal links with the microlib library which only supports a two region memory model. The construct above allows targets whose scatter file has not been ported to the new two region memory model to build using a one region memory model.

There is no difference in our memory model between full build and bare metal build. At the moment, only phase 1 of https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/platform/memory-model/ram_memory_model.md has been implemented. Heap goes from end of zero-init through the stack limit.