mkimage should 4-byte align/pad last segment

[petermm]

ESP32 flash write operations require data to be 4-byte (32-bit word) aligned.
When a firmware image has a size that is not a multiple of 4, the unaligned trailing bytes can cause write failures, if the flashing tool doesn't pad it.

Reproduce: used a webflasher to flash la_machine_4mb.img to a c3 - and the very nice runtime checksum partition check failed - flash was corrupted/missing at the end - padding to 4-byte alignment (adding two 0xff bytes to the img) made the flashing not corrupted.
(esptool.py worked fine all along as it pads the writes)

In theory we should also check that the segment offsets are 4 byte aligned.

There is a further complication for encrypted writes https://github.com/search?q=repo%3Aespressif%2Fesptool%20FLASH_ENCRYPTED_WRITE_ALIGN&type=code - which are 32 bytes aligned for esp32, and 16 bytes for all the variants - suggesting we may well just 32 bytes align everything from the get go, and be done with it.

Will PR fix once other mkimage PRs have landed..

[UncleGrumpy]

#2093 addresses this issue. I realized the last segment may not end at boundary. I didn’t not realize th padding only needed to align to a word size, so it padds to the minimum partition size of 4096. That may be too aggressive, I will change that to pad to a 32 byte boundary.

[petermm]

Oh, great - really is downstream issue with the flashing tool itself (eg. esptool.py and esptool-js handles it correctly) - but when it comes to data integrity, better safe than sorry - imho