arch/Kconfig: add image option

[Laczen]

Summary

Add extra boot memory options to enforce the use of boot memory configuration options. This allows linker files to detect if they should prefer the specified boot memory options. This supports using boot memory config without breaking the existing defconfigs.

Add image option to describe the size of an image header when a bootloader would need one.

When using the image header by a bootloader that is in nuttx-apps I would use the PREBUILD mechanism or a equivalent cmake mechanism to set the boot memory configuration and the image header size (using kconfig-tweak).

Impact

None, enabler for improving bootloader support.

Testing

tested on qemu-armv7a:nsh

...
user_main: Exiting
ostest_main: Exiting with status 0
nsh>

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[xiaoxiang781216]

but no nuttx code reference these new macro?

[Laczen]

Not yet, I wanted the OK to do it like that. I can add an example linker modification if wanted.

[Laczen]

It might be possible to avoid any additional Kconfig: depending on the meaning of "CONFIG_FLASH_START". If this is considered to be the nuttx FLASH_START it should not care if there is a image header or not. It would be the responsability of the user to take into account a header that is added to the image.

This would be logic, but it might be contradictory to the definition of board_boot_image() which takes a header size as argument.

@xiaoxiang781216, @raiden00pl what do you think is the correct interpretation of CONFIG_FLASH_START?

[acassis]

@Laczen this is a new feature, so to avoid "Another Hidden Feature of NuttX", please document it, i.e. here: https://nuttx.apache.org/docs/latest/implementation/index.html

[Laczen]

@Laczen this is a new feature, so to avoid "Another Hidden Feature of NuttX", please document it, i.e. here: https://nuttx.apache.org/docs/latest/implementation/index.html

Let us first agree on what the current meaning of the properties are in NuttX, it might be that this new feature is not needed anyway.

[Laczen]

It might be possible to avoid any additional Kconfig: depending on the meaning of "CONFIG_FLASH_START". If this is considered to be the nuttx FLASH_START it should not care if there is a image header or not. It would be the responsability of the user to take into account a header that is added to the image.

This would be logic, but it might be contradictory to the definition of board_boot_image() which takes a header size as argument.

@xiaoxiang781216, @raiden00pl what do you think is the correct interpretation of CONFIG_FLASH_START?

I think the correct understanding of CONFIG_FLASH_START should be that it is the start of the image including the header.

[xiaoxiang781216]

move the near of FLASH_START

[Laczen]

This was intentionally not done, it a ram load image is generated it could be stored on flash. The ram load part does not need the header, but to describe the image for a bootloader the header could contain e.g. where it needs to be placed in ram.

[xiaoxiang781216]

Suggested change

	#if defined(CONFIG_FLASH_START) && defined(CONFIG_FLASH_SIZE) && \
	#if defined(CONFIG_FLASH_START) && CONFIG_FLASH_START != 0

[Laczen]

The defined() are unnecessary, in theory flash_start could be zero, flash_size != 0 should be the only real condition.

[Laczen]

I think the definition of a header as used by mcuboot and nxboot can be avoided. If after the vector table or at the start of an image a small area is reserved for a magic and a image size a bootloader can find this. The image meta data (including signature) can than be added (and found) after the image.

The small area added avoids the need of defining the image header size in NuttX.