espflash save-image does not support secure padding

[ivmarkov]

Enabling ESP Secure Boot V2 means the .bin image that results from converting an app image .elf with espflash save-image should be:

• Ideally having a sha256 "integrity" hash; this is done already
• Be padded (a.k.a. secure padding) - if necessary - with an extra segment of type PADDING in such a way, that the image file total length - including the single-byte checksum and including the sha256 "integrity" hash - ends up being divisible by 65536 (i.e. image should be aligned to the 64K boundary)

The ESP IDF Python tooling can do that e.g. as follows:

cargo install --git https://github.com/ivmarkov/esptools
esptools tool --chip esp32s3 elf2image --version 2 --secure-pad-v2 --output my-firmware-padded.bin target/xtensa-esp32s3-espidf/debug/my-firmware

Looking at the resulting binary image with e.g.

esptools tool --chip esp32s3 image_info my-firmware-padded.bin

... reveals something like:

Tool esptool mounted as `/home/ivan/.cache/esptools/78c195b08bd57bf27167b323600d417a546d3393/esptool`
Executing `esptool`
esptool.py v4.8.1
File size: 1966080 (bytes)
Image version: 1
Entry point: 40376ea8
8 segments

Segment 1: len 0x7d3a8 load 0x3c140020 file_offs 0x00000018 [DROM]
Segment 2: len 0x02c48 load 0x3fc99200 file_offs 0x0007d3c8 [BYTE_ACCESSIBLE,MEM_INTERNAL,DRAM]
Segment 3: len 0x139e48 load 0x42000020 file_offs 0x00080018 [IROM]
Segment 4: len 0x03528 load 0x3fc9be48 file_offs 0x001b9e68 [BYTE_ACCESSIBLE,MEM_INTERNAL,DRAM]
Segment 5: len 0x151a0 load 0x40374000 file_offs 0x001bd398 [MEM_INTERNAL,IRAM]
Segment 6: len 0x0005c load 0x600fe000 file_offs 0x001d2540 [RTC_DRAM,RTC_IRAM]
Segment 7: len 0x00008 load 0x600fe05c file_offs 0x001d25a4 [RTC_DRAM,RTC_IRAM]
Segment 8: len 0x0da14 load 0x00000000 file_offs 0x001d25b4 [PADDING] <- !! Look here !!
Checksum: 9b (valid)
Validation Hash: 4ffc9081ffa41085b109511b82c67af4ef69828154a64692ab4f5118f1f0aeaf (valid)
Status Ok(ExitStatus(unix_wait_status(0)))

... where the tool did create the [PADDING] section in such a way, so as the total image size (1966080) is divisible by 65536, as the ESP IDF Secure Boot V2 documentation requires.

In contrast, doing

espflash save-image --chip esp32s3 target/xtensa-esp32s3-espidf/debug/my-firmware my-firmware.bin

... results in something which is not really padded - and - moreover - contains the bootloader, partition table and factory image being concatenated (which is a separate issue - but still quite an issue - altogether for which I opened another report - #714).