zephyr: vector table calculation does not address possible alignment requirements of architecture.

[de-nordic]

zephyr: vector table calculation does not address possible alignment requirements of architecture.

[nordicjm]

This is the job of the MCUboot header size, it needs to be an offset that is such that the partition start address plus the header size is a size that is compatible with the vector table address register, which for minimal cortex m3/m4/m7 implementations is 0x80, the zephyr default for these is 0x200 which gives additional spacing which can be argued is too much, but can be changed. The MCUboot header is always going to be larger than the data that is placed there, but that's going to be the case with any sector-based system, e.g. on a 4KiB sector device, if MCUboot occupies 28.5KiB, the partition size needs to be 32KiB (and depending upon security features in the MCU, some hardware-backed features might have more coarse sizes, e.g. a sector security locking system might have a 64KiB granularity, in which case MCUboot would need to be 64KiB so that it could be safely read protected, thus wasting 35.5KiB).

A flip side to having a larger header than is needed is that the header can be altered in the future, e.g. adding new TLVs or information to the image header

[de-nordic]

This is the job of the MCUboot header size, it needs to be an offset that is such that the partition start address plus the header size is a size that is compatible with the vector table address register, which for minimal cortex m3/m4/m7 implementations is 0x80, the zephyr default for these is 0x200 which gives additional spacing which can be argued is too much, but can be changed. The MCUboot header is always going to be larger than the data that is placed there, but that's going to be the case with any sector-based system, e.g. on a 4KiB sector device, if MCUboot occupies 28.5KiB, the partition size needs to be 32KiB (and depending upon security features in the MCU, some hardware-backed features might have more coarse sizes, e.g. a sector security locking system might have a 64KiB granularity, in which case MCUboot would need to be 64KiB so that it could be safely read protected, thus wasting 35.5KiB).

The problem with this is that we loose a lot of space between what is really in header and vector table. That is probably issue with Zephyr linker scripts that just shift the vtor table to proper offset, leaving the space in front of it with no data.

A flip side to having a larger header than is needed is that the header can be altered in the future, e.g. adding new TLVs or information to the image header

You can change header size between applications, the code would allow that in current state. If we would properly do the ld script in Zephyr we could take the reserved space into account.

[nordicjm]

The problem with this is that we loose a lot of space between what is really in header and vector table. That is probably issue with Zephyr linker scripts that just shift the vtor table to proper offset, leaving the space in front of it with no data.

Vector table should always come first, if you assume MCUboot itself in a device with flash address 0x0, then the vector table should reside there because that's the start of the image, that is where the CPU will begin executing from, and if it was chain loaded by a bootloader, it does not need (nor should it have) intimate knowledge of the image to be able to boot it

[de-nordic]

The problem with this is that we loose a lot of space between what is really in header and vector table. That is probably issue with Zephyr linker scripts that just shift the vtor table to proper offset, leaving the space in front of it with no data.

Vector table should always come first, if you assume MCUboot itself in a device with flash address 0x0, then the vector table should reside there because that's the start of the image, that is where the CPU will begin executing from, and if it was chain loaded by a bootloader, it does not need (nor should it have) intimate knowledge of the image to be able to boot it

That is actually not true by the arm definition itself. You can put vector table at specific addresses, they do not have to be 0, if your app does not boot from the beginning of flash. When MCUboot is used, application images do not begin with vtor, they begin with header and vtor is placed at proper offset after the header.
Closing it here, because possibility to fill in unused space should rather be addressed in Zephyr linker scripts.