gustavonihei commented on a change in pull request #4880:
URL: https://github.com/apache/incubator-nuttx/pull/4880#discussion_r756372893
##########
File path: boards/arm/samv7/same70-xplained/Kconfig
##########
@@ -90,4 +90,38 @@ config SAME70XPLAINED_HSMCI0_AUTOMOUNT_UDELAY
endif # SAME70XPLAINED_HSMCI0_AUTOMOUNT
+menuconfig SAME70XPLAINED_APP_FORMAT_MCUBOOT
+ bool "MCUboot-bootable format"
+ default n || MCUBOOT_BOOTLOADER
+ depends on BOOT_MCUBOOT
+ ---help---
+ The SAMV7 port of MCUboot supports the loading of unsegmented
firmware
+ images.
Review comment:
> [...] , but again I think that "segmented" firmware is not ESP32
specific, but more related to code located in multiple memory regions that is
usually a use case when code is executed from RAM.
That's what I tried to explain in my previous answer, but I might not have
made myself clear.
**Segments** per se are not exclusive to ESP32. Memory segments are
specified in the ELF file format.
But that specific "unsegmented" term on the help text should refer to a
characteristic of the Espressif file format (or lack of it), and that probably
does not make sense to state in this context because that's no different than
the non-MCUboot behavior for this chip.
For a ESP32 "segmented image" the information for each segment is stored in
the Image Header, which allows the segments to be juxtaposed in the binary
file, resulting in a denser binary file.
The "unsegmented" term should mean that the MCUboot image format for ESP32
does not follow the same approach. Instead it relies on the VMA and LMA
information provided via linker file, similar to the linker scripts from other
chip vendors.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
