Commit Graph

7 Commits

Author SHA1 Message Date
Ivan Grokhotkov
275ed32a11 Merge branch 'feature/esp32s2_iram_dram_protection' into 'master'
esp32s2: IRAM/DRAM memory protection

See merge request espressif/esp-idf!8156
2020-04-23 21:52:54 +08:00
Martin Vychodil
7491ea677a esp32s2: IRAM/DRAM memory protection
* new mem_prot API
* mem_prot on & locked by default (see Kconfig)
* feature activated in start_cpu0_default()

JIRA IDF-1355
2020-04-21 15:10:58 +02:00
Jakob Hasse
4943b1cbf0 CXX: make __attribute__((init_priority(n))) work
* Added corresponding test case
* Moved all C++ init tests to separate file

Closes https://github.com/espressif/esp-idf/issues/5038
2020-04-08 09:11:54 +08:00
Ivan Grokhotkov
110f3c9ff5 esp32s2: put static .data and .bss directly after .iram.text
This results in a single large heap section instead of two smaller
ones.

Closes IDF-1354
2020-01-24 10:48:38 +01:00
Ivan Grokhotkov
27bff3517f esp32s2: fix "loadable ELF" build
Closes IDF-1346
2020-01-24 10:48:20 +01:00
Ivan Grokhotkov
cbb84e8f5e esp32s2: fix THREADPTR calculation, re-enable FreeRTOS TLS tests
1. Clarify THREADPTR calculation in FreeRTOS code, explaining where
the constant 0x10 offset comes from.

2. On the ESP32-S2, .flash.rodata section had different default
alignment (8 bytes instead of 16), which resulted in different offset
of the TLS sections. Unfortunately I haven’t found a way to query
section alignment from C code, or to use a constant value to define
section alignment in the linker script. The linker scripts are
modified to force a fixed 16 byte alignment for .flash.rodata on the
ESP32 and ESP32-S2beta. Note that the base address of .flash.rodata
was already 16 byte aligned, so this has not changed the actual
memory layout of the application.

Full explanation of the calculation below.

Assume we have the TLS template section base address
(tls_section_vma), the address of a TLS variable in the template
(address), and the final relocation value (offset). The linker
calculates:
offset = address - tls_section_vma + align_up(TCB_SIZE, alignment).

At run time, the TLS section gets copied from _thread_local_start
(in .rodata) to task_thread_local_start. Let’s assume that an address
of a variable in the runtime TLS section is runtime_address.
Access to this address will happen by calculating THREADPTR + offset.
So, by a series of substitutions:

THREADPTR + offset = runtime_address THREADPTR = runtime_address - offset
THREADPTR = runtime_address - (address - tls_section_vma + align_up(TCB_SIZE, alignment)) THREADPTR = (runtime_address - address) + tls_section_vma - align_up(TCB_SIZE, alignment)

The difference between runtime_address and address is same as the
difference between task_thread_local_start and _thread_local_start.
And tls_section_vma is the address of .rodata section, i.e.
_rodata_start. So we arrive to

THREADPTR = task_thread_local_start - _thread_local_start + _rodata_start - align_up(TCB_SIZE, alignment).

The idea with TCB_SIZE being added to the THREADPTR when computing
the relocation was to let the OS save TCB pointer in the TREADPTR
register. The location of the run-time TLS section was assumed to be
immediately after the TCB, aligned to whatever the section alignment
was. However in our case the problem is that the run-time TLS section
is stored not next to the TCB, but at the top of the stack. Plus,
even if it was stored next to the TCB, the size of a FreeRTOS TCB is
not equal to 8 bytes (TCB_SIZE hardcoded in the linker). So we have
to calculate THREADPTR in a slightly obscure way, to compensate for
these differences.

Closes IDF-1239
2020-01-23 11:29:22 +01:00
morris
e30cd361a8 global: rename esp32s2beta to esp32s2 2020-01-22 12:14:38 +08:00