Ivan Grokhotkov 8ee3decdba
bootloader, esp_system: increase static allocation space for esp32s3
The previously used splits between memory allocated for ROM code,
2nd stage bootloader and the app were somewhat safe and conservative.
This resulted in some space being unavailable for static allocation
in the app.

This commit increases the space available for static allocation to the
maximum possible amount.

1. Some of the ROM code static allocation is only used in UART/USB/SPI
   download modes. This region ("shared buffers") has been placed at
   the lower end of ROM memory area, to be reusable in flash boot
   mode. The 2nd stage bootloader linker script is modified to "pack"
   all sections exactly up to the end but with roughly 8K margin between
   startup stacks.
2. Instead of calculating the sections placement and hardcoding the
   addresses in the LD script again, rewrite it to calculate the
   start address of each memory region automatically based on the
   logic above.
3. Adjust the app memory layout (SRAM_IRAM_END) accordingly,
   increasing the space available for static allocation.

Overall these changes increase the space available for static
allocation by about 78kB.

The downside of these changes is that the 2nd stage bootloader .data
segment is now directly adjacent to the startup stack on the PRO CPU.
Previously, there was effectively about 78kB of extra stack space for
the PRO CPU, before the stack would run into the data segment.
2022-06-15 17:57:11 +05:30
..
2022-05-18 20:12:25 +08:00
2021-03-31 19:17:33 +08:00
2022-03-01 19:49:24 +03:00
2021-02-24 12:16:37 +08:00
2022-05-18 20:12:25 +08:00
2021-03-25 16:09:33 +08:00

System Notes

Timekeeping

The following are the timekeeping mechanisms available and their differences:

  1. System time (esp_system_get_time)

Time with the origin at g_startup_time. The implementation is not handled by esp_system, but it does provide a default implementation using RTC timer. Currently, esp_timer provides system time, since the hardware timers are under the control of that component. However, no matter the underlying timer, the system time provider should maintain the definition of having the origin point at g_startup_time.

  1. esp_timer time (esp_timer_get_time)

This is the time read from an underlying hardware timer, controlled through config. Origin is at the point where the underlying timer starts counting.

  1. newlib time (gettimeofday)

Timekeeping function in standard library. Can be set (settimeofday) or moved forward/backward (adjtime); with the possibility of the changes being made persistent through config. Currently implemented in terms of system time, as the point of origin is fixed. If persistence is enabled, RTC time is also used in conjuction with system time.

  1. RTC time (esp_rtc_get_time_us)

Time read from RTC timer.