buildsystem: Always expose CPU_RAM_BASE & SIZE flags

[Teufelchen1]

Contribution description

Hello 🐧

This moves the definition of CPU_RAM_BASE/SIZE from being only available in certain situation to be always available.
Reason for change is to simplify common code in the cpu folder.

In cooperation with @benpicco

Testing procedure

Passing CI

Issues/PRs references

First usage will be in the PMP driver. Although there is more code in RIOT that could be refactored to use these defines instead of hacks / hardcoded values.

[riot-ci]

Murdock results

✔️ PASSED

791d4e3 buildsystem: Always expose CPU_RAM_BASE & SIZE flags

Success	Failures	Total	Runtime
6934	0	6934	11m:17s

Artifacts

• Documentation preview

[benpicco]

bors merge

[bors]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• Murdock
• static-tests
• tools-build-success

[maribu]

This causes

/bin/sh: 1: arithmetic expression: expecting primary: ""

in the CI :-/

[gschorcht]

This causes

/bin/sh: 1: arithmetic expression: expecting primary: ""

in the CI :-/

It happens for ESP32x because RAM_LEN is not defined.

[gschorcht]

Hm, the problem with ESP32x SoC is that they don't have that only one RAM but a number of SRAMs of different sizes, different byte/word access requirements and mapped into different address spaces. Additionally, parts of these SRAMS are used by different hardware components like cache, BT, ...

Just for example an ESP32 has 520 kB SRAM:

Memory	Size	Address Space Data Bus	Remark
SRAM0	192 kB	-	accessible word-wise via Instruction Bus
SRAM1	128 kB	03xFFE0000 - 0x3FFFFFFF	accessible word-wise via Instruction Bus
SRAM2	200 kB	0x3FFAE000 - 0x3FFDFFFF	first 8 kByte are used as cache
RTC	8 kB	-	accessible word-wise via Instruction Bus

The memory.ld.in file which is used directly from the ESP-IDF, defines the usable RAM region as follows:

#define DRAM0_0_SEG_LEN 0x2c200

dram0_0_seg (RW) : org = 0x3FFB0000 + CONFIG_BTDM_RESERVE_DRAM,
                   len = DRAM0_0_SEG_LEN - CONFIG_BTDM_RESERVE_DRAM

That is, only SRAM2 is used as RAM. So we could use 0x3FFB0000 as RAM_START_ADDR if we don't use BT. But if we use BT, the size and the start address of RAM changes because the BT Controller is using the RAM at 0x3FFB0000.

It becomes even more difficult for ESP32-S3. Here the memory.ld.in file computes usable RAM
region and size based on a number of configurations:

#define DRAM_ORG    (RAM_DRAM_START + CONFIG_ESP32S2_INSTRUCTION_CACHE_SIZE \
                                    + CONFIG_ESP32S2_DATA_CACHE_SIZE)

dram0_0_seg (RW) : org = DRAM_ORG, len = I_D_RAM_SIZE - STATIC_RAM_SIZE

[maribu]

At least for native we cannot expose those anyway. So portable code cannot rely on this macros to be sensible anyway.

I expect those only to be used in CPU specific drivers such as memory protection units, DMA drivers, etc. Those will likely have a good understanding of the memory layout and only make use of the macros if they make sense in the context of the platform.

I think it is also fine for platforms that have a more complex memory layout to just not provide these macros. It is better to have no info, than an oversimplification that is misleading.

(But when those macros do match the actual memory layout, I think it is absoutly fine to expose them.)