It is now possible to have any alignment restriction on rodata in the user
applicaiton. It will not affect the first section which must be aligned
on a 16-byte bound.
Closes https://github.com/espressif/esp-idf/issues/6719
The CPU might prefetch instructions, which means it in some cases
will try to fetch instruction located after the last instruction in
flash.text.
Add dummy bytes to ensure fetching these wont result in an error,
e.g. MMU exceptions
Bootloader DRAM now ends at 0x3FFEAB00 which is the start of ROM
static RAM (reclaimable after app is running).
IRAM loader segment increased by 8KB.
Available total static RAM for the app is now reduced by 16KB.
This commit adds TWAI driver support for the
ESP32-S2. The following features were added:
- Expanded BRP support
- Expanded CLKOUT Divider Support
- Updated example READMEs
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
