Add a new CMake function esp_partition_flash_binary() that provides a
unified API for registering partition data binaries to be flashed. It
replaces the direct esptool_py_flash_target calls scattered across
components (spiffs, fatfs, nvs_flash) with a single function that:
- Resolves partition offset from the partition table automatically
- Determines encryption requirements (auto-detect or ALWAYS_PLAINTEXT)
- Creates per-partition flash targets (e.g. idf.py <partition>-flash)
- Optionally includes the binary in `idf.py flash` via FLASH_IN_PROJECT
On the linux target, the function registers binaries for pre-loading
into the emulated flash. A build-time manifest (linux_flash_data.txt)
is generated via file(GENERATE), and partition_linux.c reads it at
runtime to copy each binary into the memory-mapped flash buffer at
the correct offset.
The partition_ops example is updated to use the new function and
includes a custom_partition with pre-built data to demonstrate the
full workflow, including on the linux target.
Currently, the bootloader version of the `esp_partition` component sets
`PRIV_INCLUDE_DIRS` using the `private_include_dirs` variable. However,
this variable is not properly initialized, which causes issues in
cmakev2. In cmakev2, components are evaluated recursively, and a
component may be evaluated in the context of another component, so
components must initialize all variables before using them.
Moreover, there are effectively no `PRIV_INCLUDE_DIRS` to set when the
component is evaluated for the bootloader. Therefore, remove
`PRIV_INCLUDE_DIRS` entirely for bootloader and test builds.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
* Users can now use libbsd string.h and sys/cdefs.h functionality
(e.g., strlcpy, containerof) on Linux by just including
string.h or sys/cdefs.h. In other words, the includes are the same
on the Linux target as well as on chips targets (ESP32, etc.).
* libbsd linking is done by the linux component (belongs to common
components) now instead of handling it separately in each component
All the partition handling API functions and data-types were moved from the 'spi_flash' component to the new one named 'esp_partition'. See Storage 5.x migration guide for more details