[dgarske]

Description

COMPRESSED_UPDATE=1 holds the update partition as a gzip-compressed, signed image and inflates it into the boot partition, which goes on executing in place. The update partition is then sized for the container rather than for a second full copy, and the flash that frees goes to the application instead.

The update partition may be internal, on external flash, or on external flash encrypted at rest with the existing ENCRYPT=1 layer. The last two work because the decoder can pull its input through a callback rather than reading it in place, and ext_flash_check_read() is already the point where an encrypted partition is decrypted.

There is no local copy of the outgoing image, so this trades rollback for flash. Three things bound that: the container is verified before the first erase, so a bad image never touches the running one; the update partition is only ever read during an install, so a power cut leaves an intact source and the next boot resumes from the recorded progress; and the payload is a complete signed image, so the boot partition stays an ordinary wolfBoot partition that the normal boot path verifies, meaning the inflater need not be trusted.

What it adds

• src/update_flash.c - the installer, built on the existing DISABLE_BACKUP path
• src/gzip.c - a sink decoder with a bounded LZ77 window and an optional input callback, selected at build time, leaving the flat decoder the FIT path uses unchanged
• tools/keytools/sign.c - --compress[=bits], which compresses and signs the nested container; zlib is an optional dependency and the option is rejected without it
• WOLFBOOT_PARTITION_UPDATE_SIZE smaller than the boot partition, which the existing monolithic self-update sizing already allowed in the other direction
• Example configs for all three layouts, docs/Compression.md, simulator tests, unit tests and CI

Fixes in shared code

• START_FLAGS_OFFSET is derived from the boot partition but applied to the update partition, so with the two sized independently the update trailer fell outside the plaintext window and would be encrypted along with the image. Sized from the update slot now; identical for a symmetric layout.
• wb_trailer_clear() cleared the update partition's trailer at the boot partition's size offset
• hal/stm32f4.c describes 1MB of flash, so a partition past that silently failed to erase; now refused at build time
• hal/stm32h7.h derives the write-once flags page from the partition end, and the H7 cannot erase less than a sector, so a partition that was not a whole number of sectors had that erase reach into the neighbouring one. stm32h7.config was 6.5 sectors, which put the BOOT flags page over the first 64KB of UPDATE and made rollback impossible. Guarded at build time, and the example, presets and CMake docs are now sector-aligned.
• DEBUG_UART=1 on TARGET=stm32f4 hung on the first print, because nothing initialized the port

Testing

Simulator tests cover all three layouts across two signature algorithms, and the internal-flash layout at both the smallest and the default window. Unit tests compare the sink decoder against the flat one over the existing fixture corpus at every window, including input delivered through a callback, and check that a short or failing source is rejected rather than yielding a truncated image.

Hardware validation on a NUCLEO-F439ZI covered the internal-flash install, the update being consumed rather than repeated, and resume after an interrupted install. That board has no external flash wired, so the external and encrypted layouts are simulator-only.

[danielinux]

I see this is more generic now. Looks good.

Please double check the interaction with the new NVM_FLASH_ECC journaling (mandated for some targets e.g. aurix tc3xx). Either exclude the combination (#error out on NVM_FLASH_ECC + COMPRESSED_UPDATE), or pad the final chunk to align to the write unit.