-
Notifications
You must be signed in to change notification settings - Fork 717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for RAMLOAD mode with revert #2197
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -330,6 +330,12 @@ int boot_save_shared_data(const struct image_header *hdr, const struct flash_are | |
BLINFO_RUNNING_SLOT, | ||
sizeof(slot), (void *)&slot); | ||
} | ||
|
||
if (!rc) { | ||
rc = boot_add_data_to_shared_area(TLV_MAJOR_BLINFO, | ||
BLINFO_FLASH_AREA, | ||
sizeof(fap->fa_id), (void *)&fap->fa_id); | ||
} | ||
Comment on lines
+334
to
+338
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Three issues:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, makes sense. I have no issue changing this, really all I want is a workable solution for indicating the flash area that Zephyr's MCUBoot subsystem should use when marking an image as confirmed. Is there an API for mapping the boot slot number back to a flash area we can use? |
||
#endif | ||
|
||
#if defined(MCUBOOT_VERSION_AVAILABLE) | ||
|
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -344,6 +344,17 @@ config BOOT_DIRECT_XIP_REVERT | |||||
attempt to boot the previous image. The images can also be made permanent | ||||||
(marked as confirmed in advance) just like in swap mode. | ||||||
|
||||||
config BOOT_RAM_LOAD_REVERT | ||||||
bool "Enable the revert mechanism in ramload mode" | ||||||
depends on BOOT_RAM_LOAD | ||||||
help | ||||||
If y, enables the revert mechanism in ramload similar to the one in | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
swap mode. It requires the trailer magic to be added to the signed image. | ||||||
When a reboot happens without the image being confirmed at runtime, the | ||||||
bootloader considers the image faulty and erases it. After this it will | ||||||
attempt to boot the previous image. The images can also be made permanent | ||||||
(marked as confirmed in advance) just like in swap mode. | ||||||
|
||||||
config BOOT_BOOTSTRAP | ||||||
bool "Bootstrap erased the primary slot from the secondary slot" | ||||||
default n | ||||||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
/ { | ||
sram@80007F00 { | ||
compatible = "zephyr,memory-region", "mmio-sram"; | ||
reg = <0x80007F00 0x100>; | ||
zephyr,memory-region = "RetainedMem"; | ||
status = "okay"; | ||
|
||
retainedmem { | ||
compatible = "zephyr,retained-ram"; | ||
status = "okay"; | ||
#address-cells = <1>; | ||
#size-cells = <1>; | ||
|
||
boot_info0: boot_info@0 { | ||
compatible = "zephyr,retention"; | ||
status = "okay"; | ||
reg = <0x0 0x100>; | ||
}; | ||
}; | ||
}; | ||
|
||
chosen { | ||
zephyr,bootloader-info = &boot_info0; | ||
zephyr,code-partition = &boot_partition; | ||
}; | ||
}; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
/ { | ||
sram@2003FF00 { | ||
compatible = "zephyr,memory-region", "mmio-sram"; | ||
reg = <0x2003FF00 0x100>; | ||
zephyr,memory-region = "RetainedMem"; | ||
status = "okay"; | ||
|
||
retainedmem { | ||
compatible = "zephyr,retained-ram"; | ||
status = "okay"; | ||
#address-cells = <1>; | ||
#size-cells = <1>; | ||
|
||
boot_info0: boot_info@0 { | ||
compatible = "zephyr,retention"; | ||
status = "okay"; | ||
reg = <0x0 0x100>; | ||
}; | ||
}; | ||
}; | ||
|
||
chosen { | ||
zephyr,bootloader-info = &boot_info0; | ||
zephyr,code-partition = &boot_partition; | ||
}; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this already done vis BLINFI_RUNNING_SLOT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RUNNING_SLOT
gives the index of the active slot, but for the MCUBoot subsystem code in Zephyr we need access to the flash area ID. For example, Slot 0 on the RT1050 has flash area ID 1 (because the MCUBoot partition has area ID 0)We could change the value set by
RUNNING_SLOT
, but I wanted to avoid breaking any APIs so I added this. It was needed in order to get features like confirming a running image working with MCUBootThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have to convert from running slot to flash area ID in your application itself, as img mgmt does e.g. https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/mgmt/mcumgr/grp/img_mgmt/src/zephyr_img_mgmt.c#L128 the flash area ID has no meaning between different applications e.g. application could have bootloader slot split into 2 in future, now you open the wrong thing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, ok. I was testing this with the DFU subsystem- so would it make sense to call
img_mgmt_flash_area_id
here inboot_fetch_active_slot
: https://github.com/zephyrproject-rtos/zephyr/pull/85254/files#diff-696b0049cfb981ee66f0191ccaf755f25a632c35b86da7dc1d739c3de8a60ed3L78? Otherwise, functions like marking the image as pending weren't working, sinceboot_fetch_active_slot
is really fetching the flash area ID of the active slot, not the slot number.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That returns either:
Which should then be used to check if it's slot0 if 0 or slot1 if 1 (it doesn't care about additional images since they are not "running"),