Aksal/nuttx-apps
1
0
Fork 1
mirror of https://github.com/apache/nuttx-apps.git synced 2026-10-16 02:01:47 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
nuttx-apps/boot/nxboot/Kconfig

160 lines
5.1 KiB
Text
Raw Normal View History

boot: add NuttX bootloader with update and recovery support This commit adds NuttX based bootloader with the support for image update and recovery if not confirmed. The algorithm utilizes three flash partitions: primary (image runs from this area), secondary and tertiary. Secondary and tertiary areas are used for update upload and recovery. The update is performed by simple copy from update area to primary area with recovery being created in recovery area if not already present. Once image is confirmed by the user, the image in update area is confirmed as well, update area becomes recovery area and vice versa. This means the recovery is always present (except for the first update) and subsequent updates just copy image from update to primary. This makes the update significantly faster and more considerable to flash wear while keeping the recovery/revert possibility. A header (aligned to flash's erase size) must be added to the beginning of the image. Python script nximage.py can be used to prepend this header to built binary. The algorithm also uses one erase page at the end of a partition (partition, not image!) to store flags used to indicate image confirm status and to detect update/recovery partitions. Any program uploading update image to the update partition has to erase this page for the boot to work correctly! The algorithm implementation is based on a patch initially developed for MCUboot project but rejected by the project's maintainers https://github.com/mcu-tools/mcuboot/pull/1902 Signed-off-by: Michal Lenc <michallenc@seznam.cz>
2024-10-20 20:48:58 +02:00
#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#
menuconfig BOOT_NXBOOT
bool "NuttX bootloader"
default n
select BCH
---help---
Enable support for the minimal NuttX based bootloader.
if BOOT_NXBOOT
config NXBOOT_PRIMARY_SLOT_PATH
string "Application firmware primary image slot path"
default "/dev/ota0"
---help---
The path to the application firmware image primary slot character
device driver. The image runs from this location.
Default: /dev/ota0
config NXBOOT_SECONDARY_SLOT_PATH
string "Application firmware secondary image slot path"
default "/dev/ota1"
---help---
The path to the application firmware image primary slot character
device driver. This is either update or recovery slot.
Default: /dev/ota1
config NXBOOT_TERTIARY_SLOT_PATH
string "Application firmware tertiary image slot path"
default "/dev/ota2"
---help---
The path to the application firmware image primary slot character
device driver. This is either update or recovery slot.
Default: /dev/ota2
config NXBOOT_HEADER_SIZE
hex "Application firmware image header size"
default 0x200
---help---
boot/nxboot: improve documentation Previously it was hard to guess the correct entrypoint for the bootloader application. Signed-off-by: Lars Kruse <devel@sumpfralle.de>
2025-09-17 10:16:42 +02:00
The nxboot bootloader itself requires only a few bytes of header
data. Increase this value, if you need to store additional
application-specific meta data.
boot: add NuttX bootloader with update and recovery support This commit adds NuttX based bootloader with the support for image update and recovery if not confirmed. The algorithm utilizes three flash partitions: primary (image runs from this area), secondary and tertiary. Secondary and tertiary areas are used for update upload and recovery. The update is performed by simple copy from update area to primary area with recovery being created in recovery area if not already present. Once image is confirmed by the user, the image in update area is confirmed as well, update area becomes recovery area and vice versa. This means the recovery is always present (except for the first update) and subsequent updates just copy image from update to primary. This makes the update significantly faster and more considerable to flash wear while keeping the recovery/revert possibility. A header (aligned to flash's erase size) must be added to the beginning of the image. Python script nximage.py can be used to prepend this header to built binary. The algorithm also uses one erase page at the end of a partition (partition, not image!) to store flags used to indicate image confirm status and to detect update/recovery partitions. Any program uploading update image to the update partition has to erase this page for the boot to work correctly! The algorithm implementation is based on a patch initially developed for MCUboot project but rejected by the project's maintainers https://github.com/mcu-tools/mcuboot/pull/1902 Signed-off-by: Michal Lenc <michallenc@seznam.cz>
2024-10-20 20:48:58 +02:00
Note that this size should be aligned with the program memory write
page size!
boot/nxboot: enhance bootloader capabilities and decision logic This commit enhances the bootloader capabilities. The image's header is extended with header version, size, platform identifier and pointer to optional next header. CRC32 now includes part of the header in its calculation as well. The change also avoids having two different magics for image uploaded over programmer and update image. Both these images have the same magic and this magic is changed internally by the bootloader's logic. The change is needed because image with standard magic is automatically considered as a confirmed image (uploaded with programmer). The current implementation avoids tails at all, therefore the user application uploading the image does not have to erase the tail before new upload. The image is considered as confirmed if it has standard magic or its recovery is present. This means the bootloader has to erase the header of the update image after the update is done (to avoid update loop and to mark the image as unstable). This page is written back during the confirmation. This is a breaking change, but necessary for the future development of the bootloader. The added header version field will allow to add minor/major updates while keeping the backwards compatibility. Signed-off-by: Michal Lenc <michallenc@seznam.cz> Co-authored-by: Pavel Pisa <pisa@fel.cvut.cz> Co-authored-by: Karel Koci <cynerd@email.cz>
2025-03-10 13:16:25 +01:00
config NXBOOT_PLATFORM_IDENTIFIER
hex "A unique platform identifier"
default 0x0
---help---
This is a unique platform identifier used by the bootloader to
verify whether the image should be run on a given platform. An update
(or even a firmware uploaded via a programmer) is rejected if the
value in image's header doesn't match this option.
boot: add NuttX bootloader with update and recovery support This commit adds NuttX based bootloader with the support for image update and recovery if not confirmed. The algorithm utilizes three flash partitions: primary (image runs from this area), secondary and tertiary. Secondary and tertiary areas are used for update upload and recovery. The update is performed by simple copy from update area to primary area with recovery being created in recovery area if not already present. Once image is confirmed by the user, the image in update area is confirmed as well, update area becomes recovery area and vice versa. This means the recovery is always present (except for the first update) and subsequent updates just copy image from update to primary. This makes the update significantly faster and more considerable to flash wear while keeping the recovery/revert possibility. A header (aligned to flash's erase size) must be added to the beginning of the image. Python script nximage.py can be used to prepend this header to built binary. The algorithm also uses one erase page at the end of a partition (partition, not image!) to store flags used to indicate image confirm status and to detect update/recovery partitions. Any program uploading update image to the update partition has to erase this page for the boot to work correctly! The algorithm implementation is based on a patch initially developed for MCUboot project but rejected by the project's maintainers https://github.com/mcu-tools/mcuboot/pull/1902 Signed-off-by: Michal Lenc <michallenc@seznam.cz>
2024-10-20 20:48:58 +02:00
config NXBOOT_BOOTLOADER
bool "Build nxboot bootloader application"
default n
select BOARDCTL
select BOARDCTL_BOOT_IMAGE
---help---
This option builds and links a bootloader application. This application
boot/nxboot: improve documentation Previously it was hard to guess the correct entrypoint for the bootloader application. Signed-off-by: Lars Kruse <devel@sumpfralle.de>
2025-09-17 10:16:42 +02:00
("nxboot_loader_main") should be the entry function for NuttX.
It checks for a possible update/revert operation, performs it and boots
the correct image.
boot: add NuttX bootloader with update and recovery support This commit adds NuttX based bootloader with the support for image update and recovery if not confirmed. The algorithm utilizes three flash partitions: primary (image runs from this area), secondary and tertiary. Secondary and tertiary areas are used for update upload and recovery. The update is performed by simple copy from update area to primary area with recovery being created in recovery area if not already present. Once image is confirmed by the user, the image in update area is confirmed as well, update area becomes recovery area and vice versa. This means the recovery is always present (except for the first update) and subsequent updates just copy image from update to primary. This makes the update significantly faster and more considerable to flash wear while keeping the recovery/revert possibility. A header (aligned to flash's erase size) must be added to the beginning of the image. Python script nximage.py can be used to prepend this header to built binary. The algorithm also uses one erase page at the end of a partition (partition, not image!) to store flags used to indicate image confirm status and to detect update/recovery partitions. Any program uploading update image to the update partition has to erase this page for the boot to work correctly! The algorithm implementation is based on a patch initially developed for MCUboot project but rejected by the project's maintainers https://github.com/mcu-tools/mcuboot/pull/1902 Signed-off-by: Michal Lenc <michallenc@seznam.cz>
2024-10-20 20:48:58 +02:00
if NXBOOT_BOOTLOADER
apps/boot/nxboot: Enhancements to add progress messages and copy-to-RAM feature This adds Kconfig-enabled progress messages that are output to stdout. It also adds Kconfig-enabled option to copy the validated and bootable image to RAM Signed-off by: Tim Hardisty <timh@jti.uk.com>
2025-04-24 11:15:26 +01:00
config NXBOOT_COPY_TO_RAM
bool "Copy bootable image to RAM before calling board boot-image function"
default n
---help---
The is a board and/or arch specific option that may be used when running
directly from flash, especially if external flash, even in XIP mode, is too
slow.
Running from RAM usually results in faster execution but the board must, of
course, have sufficient RAM available for the application image, stack
and heap.
config NXBOOT_RAMSTART
hex "Start address in RAM that the application is to be loaded"
default 0x0
depends on NXBOOT_COPY_TO_RAM
---help---
This will be board specific. A check of the board's linker script
may be informative. For example the SAMA5D2-XULT eval board's uboot
linker script - boards/arm/sama5/sama5d2-xult/scripts/uboot.ld - has:
sdram (W!RX) : ORIGIN = 0x20008000, LENGTH = 256M - 32K
This shows the load address to be 0x20008000 and would be the address
to use here if the same linker script is to be be used for NXboot.
Typically the address is the base address of the RAM to be used, plus the
size of the NXboot image itself. The example above has reserved
32KiB (0x8000) for this from the 256MiB available on the board at
address 0x20000000.
boot: add NuttX bootloader with update and recovery support This commit adds NuttX based bootloader with the support for image update and recovery if not confirmed. The algorithm utilizes three flash partitions: primary (image runs from this area), secondary and tertiary. Secondary and tertiary areas are used for update upload and recovery. The update is performed by simple copy from update area to primary area with recovery being created in recovery area if not already present. Once image is confirmed by the user, the image in update area is confirmed as well, update area becomes recovery area and vice versa. This means the recovery is always present (except for the first update) and subsequent updates just copy image from update to primary. This makes the update significantly faster and more considerable to flash wear while keeping the recovery/revert possibility. A header (aligned to flash's erase size) must be added to the beginning of the image. Python script nximage.py can be used to prepend this header to built binary. The algorithm also uses one erase page at the end of a partition (partition, not image!) to store flags used to indicate image confirm status and to detect update/recovery partitions. Any program uploading update image to the update partition has to erase this page for the boot to work correctly! The algorithm implementation is based on a patch initially developed for MCUboot project but rejected by the project's maintainers https://github.com/mcu-tools/mcuboot/pull/1902 Signed-off-by: Michal Lenc <michallenc@seznam.cz>
2024-10-20 20:48:58 +02:00
config NXBOOT_SWRESET_ONLY
bool "Perform update/revert only on SW reset"
default n
select BOARDCTL_RESET_CAUSE
---help---
This option ensures the update/revert is performed only for following
reset causes:
BOARDIOC_RESETCAUSE_CPU_SOFT: software reset
BOARDIOC_RESETCAUSE_CPU_RWDT: watchdog error
BOARDIOC_RESETCAUSE_PIN: reset button
This way the board can keep its image (even if not confirmed) during
for example power shutdown and perform update/revent only if expected
based on user/maintainer input.
config NXBOOT_PREVENT_DOWNGRADE
bool "Perform update only for newer version"
default n
---help---
NXboot uses Semantic Version 2.0.0 (without build metadata). By default
the update is performed for every version that doesn't match the
currently running one. If NXBOOT_PREVENT_DOWNGRADE selected, update is
apps/boot/nxboot: Enhancements to add progress messages and copy-to-RAM feature This adds Kconfig-enabled progress messages that are output to stdout. It also adds Kconfig-enabled option to copy the validated and bootable image to RAM Signed-off by: Tim Hardisty <timh@jti.uk.com>
2025-04-24 11:15:26 +01:00
performed only for newer versions (according to Semantic Version
boot: add NuttX bootloader with update and recovery support This commit adds NuttX based bootloader with the support for image update and recovery if not confirmed. The algorithm utilizes three flash partitions: primary (image runs from this area), secondary and tertiary. Secondary and tertiary areas are used for update upload and recovery. The update is performed by simple copy from update area to primary area with recovery being created in recovery area if not already present. Once image is confirmed by the user, the image in update area is confirmed as well, update area becomes recovery area and vice versa. This means the recovery is always present (except for the first update) and subsequent updates just copy image from update to primary. This makes the update significantly faster and more considerable to flash wear while keeping the recovery/revert possibility. A header (aligned to flash's erase size) must be added to the beginning of the image. Python script nximage.py can be used to prepend this header to built binary. The algorithm also uses one erase page at the end of a partition (partition, not image!) to store flags used to indicate image confirm status and to detect update/recovery partitions. Any program uploading update image to the update partition has to erase this page for the boot to work correctly! The algorithm implementation is based on a patch initially developed for MCUboot project but rejected by the project's maintainers https://github.com/mcu-tools/mcuboot/pull/1902 Signed-off-by: Michal Lenc <michallenc@seznam.cz>
2024-10-20 20:48:58 +02:00
preference rules).
boot/nxboot: enhance bootloader capabilities and decision logic This commit enhances the bootloader capabilities. The image's header is extended with header version, size, platform identifier and pointer to optional next header. CRC32 now includes part of the header in its calculation as well. The change also avoids having two different magics for image uploaded over programmer and update image. Both these images have the same magic and this magic is changed internally by the bootloader's logic. The change is needed because image with standard magic is automatically considered as a confirmed image (uploaded with programmer). The current implementation avoids tails at all, therefore the user application uploading the image does not have to erase the tail before new upload. The image is considered as confirmed if it has standard magic or its recovery is present. This means the bootloader has to erase the header of the update image after the update is done (to avoid update loop and to mark the image as unstable). This page is written back during the confirmation. This is a breaking change, but necessary for the future development of the bootloader. The added header version field will allow to add minor/major updates while keeping the backwards compatibility. Signed-off-by: Michal Lenc <michallenc@seznam.cz> Co-authored-by: Pavel Pisa <pisa@fel.cvut.cz> Co-authored-by: Karel Koci <cynerd@email.cz>
2025-03-10 13:16:25 +01:00
WARNING: NXboot currently implements preferences only for
boot: add NuttX bootloader with update and recovery support This commit adds NuttX based bootloader with the support for image update and recovery if not confirmed. The algorithm utilizes three flash partitions: primary (image runs from this area), secondary and tertiary. Secondary and tertiary areas are used for update upload and recovery. The update is performed by simple copy from update area to primary area with recovery being created in recovery area if not already present. Once image is confirmed by the user, the image in update area is confirmed as well, update area becomes recovery area and vice versa. This means the recovery is always present (except for the first update) and subsequent updates just copy image from update to primary. This makes the update significantly faster and more considerable to flash wear while keeping the recovery/revert possibility. A header (aligned to flash's erase size) must be added to the beginning of the image. Python script nximage.py can be used to prepend this header to built binary. The algorithm also uses one erase page at the end of a partition (partition, not image!) to store flags used to indicate image confirm status and to detect update/recovery partitions. Any program uploading update image to the update partition has to erase this page for the boot to work correctly! The algorithm implementation is based on a patch initially developed for MCUboot project but rejected by the project's maintainers https://github.com/mcu-tools/mcuboot/pull/1902 Signed-off-by: Michal Lenc <michallenc@seznam.cz>
2024-10-20 20:48:58 +02:00
MAJOR.MINOR.PATCH and ignores prerelease.
boot/nxboot: fix compile errors caused by nxboot_progress Function nxboot_progress is located in nxboot_main.c, but this file is not compiled when NXboot is used as a library to an existing application and not as a bootloader. Therefore, the declaration of nxboot_progress function should be dependent on NXBOOT_PROGRESS config option. Signed-off-by: Michal Lenc <michallenc@seznam.cz>
2025-06-16 10:09:14 +02:00
config NXBOOT_PROGRESS
bool
default n
apps/boot/nxboot: Enhancements to add progress messages and copy-to-RAM feature This adds Kconfig-enabled progress messages that are output to stdout. It also adds Kconfig-enabled option to copy the validated and bootable image to RAM Signed-off by: Tim Hardisty <timh@jti.uk.com>
2025-04-24 11:15:26 +01:00
config NXBOOT_PRINTF_PROGRESS
bool "Enable progress messages to be sent to STDOUT"
default y
boot/nxboot: fix compile errors caused by nxboot_progress Function nxboot_progress is located in nxboot_main.c, but this file is not compiled when NXboot is used as a library to an existing application and not as a bootloader. Therefore, the declaration of nxboot_progress function should be dependent on NXBOOT_PROGRESS config option. Signed-off-by: Michal Lenc <michallenc@seznam.cz>
2025-06-16 10:09:14 +02:00
select NXBOOT_PROGRESS
apps/boot/nxboot: Enhancements to add progress messages and copy-to-RAM feature This adds Kconfig-enabled progress messages that are output to stdout. It also adds Kconfig-enabled option to copy the validated and bootable image to RAM Signed-off by: Tim Hardisty <timh@jti.uk.com>
2025-04-24 11:15:26 +01:00
---help---
This will display progress during typically lengthy operations:
- Calculating checksums
- copying images between slots
Note: the NXboot binary will be approximately 2KiB larger with this enabled.
choice
prompt "Choose preferred progress indication type"
depends on NXBOOT_PRINTF_PROGRESS
default NXBOOT_PRINTF_PROGRESS_PERCENT
config NXBOOT_PRINTF_PROGRESS_DOTS
bool "Display progress using sequential dots"
config NXBOOT_PRINTF_PROGRESS_PERCENT
bool "Display progress using percentage remaining"
endchoice
boot: add NuttX bootloader with update and recovery support This commit adds NuttX based bootloader with the support for image update and recovery if not confirmed. The algorithm utilizes three flash partitions: primary (image runs from this area), secondary and tertiary. Secondary and tertiary areas are used for update upload and recovery. The update is performed by simple copy from update area to primary area with recovery being created in recovery area if not already present. Once image is confirmed by the user, the image in update area is confirmed as well, update area becomes recovery area and vice versa. This means the recovery is always present (except for the first update) and subsequent updates just copy image from update to primary. This makes the update significantly faster and more considerable to flash wear while keeping the recovery/revert possibility. A header (aligned to flash's erase size) must be added to the beginning of the image. Python script nximage.py can be used to prepend this header to built binary. The algorithm also uses one erase page at the end of a partition (partition, not image!) to store flags used to indicate image confirm status and to detect update/recovery partitions. Any program uploading update image to the update partition has to erase this page for the boot to work correctly! The algorithm implementation is based on a patch initially developed for MCUboot project but rejected by the project's maintainers https://github.com/mcu-tools/mcuboot/pull/1902 Signed-off-by: Michal Lenc <michallenc@seznam.cz>
2024-10-20 20:48:58 +02:00
endif # NXBOOT_BOOTLOADER
endif # BOOT_NXBOOT
Reference in a new issue Copy permalink