bootloader: add riotboot minimal bootloader#10065
bootloader: add riotboot minimal bootloader#10065emmanuelsearch merged 8 commits intoRIOT-OS:masterfrom
Conversation
a6721e5 to
0d2a562
Compare
|
Why did you cut out the slot selection logic? |
From the description it looks like this is a minimal version that only supports a single firmware slot. |
Yup, but my original commit contained like, ~15 lines more, but did support multiple slots. IMO, going through all the bootloader hoops to verify a firmware's metadata hash seems a bit pointless. |
I wanted to provide the minimal as possible and then build on top of it the extensions, like support for two firmware slots and flashing. I think I can re-add this logic since it doesn't hurt, but it will look like we're looking for inexistent slots (there are no support for second slot here). Anyways, there are some current problems to be solved first, after solve them I can get back into this question. |
|
@kYc0o any eta on when you will push the changes? |
Marking WIP because of this.
Should be done by tomorrow at latest. |
584dfa6 to
fcec3c6
Compare
|
Not WIP anymore. I changed several conceptual things on this PR and remove some awful dependencies which were not needed. Now, slot 0 represents the first firmware image, while the bootloader represents no slot. This change was to be aligned on other bootloaders (e.g. mcuboot) slot concepts, and actually having slot 0 as the bootloader wasn't really useful.
The compilation of Finally, I don't know how to get rid of the cppcheck error, in my system I don't have it, most likely because I have a more recent cppcheck version. |
5b924f3 to
dbb74e3
Compare
|
Pushed some changes to get rid of the cppcheck error. Although, it was a false negative IMHO so we should update Murdock to avoid those. |
|
@kYc0o first commit reads "cpu/cortexm_common: initial multislot support". |
|
|
@cladmi must the docker aspect you mention be part of this PR (or can it be a subsequent PR)? |
|
@jcarrano what is blocking (if anything) in your comments, from your point of view? |
It's easier to fix it myself in a PR later.
|
ping @cladmi |
|
@emmanuelsearch issue is also present for |
Not much time to review the details, but test works and also helped with some of the implementation.
|
Please squash and rebase. @kaspar030 do you need any more changes before merging? |
|
IMO this is good to go. Please squash! |
This module adds some helper function to manage slots created with a riotboot_hdr header. Co-authored-by: Kaspar Schleiser <[email protected]>
In order to use the RIOT bootloader (riotboot) a header needs to be created and placed before the firmware. This tool generates such a header with the expected information by the bootloader. Co-authored-by: Kaspar Schleiser <[email protected]>
riotboot is introduced here and makes use of riotboot_hdr, which indentifies the images encapsulated as slots. The slot size and offset is configurable, which makes slots extendable if needed, e.g. 2 or more slots can be transparently added. Co-authored-by: Kaspar Schleiser <[email protected]> Co-authored-by: Gaëtan Harter <[email protected]>
This new function allows to jump to another execution environment (VTOR) located at a certain (aligned) address. It's used to boot firmwares at another location than `CPU_FLASH_BASE`. The user needs to ensure that the CPU using this feature is able to be initialised at least twice while jumping to the RIOT `reset_handler_default` function, since it initialises the CPU again (calls cpu_init()). Co-authored-by: Kaspar Schleiser <[email protected]>
RIOTBOOT_SLOT_LEN is calculated as an hexadecimal value and handles ROM_LEN defined as kilobytes like '512K' This enables support for all the cortex-m0+/3/4/7 arch, so most boards embedding these are potentially supported. One needs just to ensure that the CPU can be initialised at least twice. Co-authored-by: Gaëtan Harter <[email protected]>
Currently only tested boards provide the feature riotboot. Potentially all boards embeding a cortex-m0+/3/4/7 are able to have riotboot as a feature, but other dependencies need to be met, e.g. usage of cortexm.ld linker script, double initialisation of cpu_init(), etc. See doc in bootloaders/riotboot.
The tests overrides the target all to be tested by the CI. All the instructions how to use it are in README.md The test is successful if the image boots and displays information about the image and running slot. Co-authored-by: Federico Pellegrin <[email protected]>
Co-authored-by: Federico Pellegrin <[email protected]>
10aca80 to
66911d6
Compare
|
I squashed as @kYc0o is currently offline. As I co-authored most of the code, we'll need more than my ACK. Anyhow, I think we should get this in ASAP. We can always iterate. |
|
@kaspar030 we have another ACK from @danpetry so we're good if Murdock is green. |
|
🎉 |
|
😃 a big thanks to all the contributors and reviewers for making this PR in! |
We don't want forget this: Can you create issues or the PR timely. |
Contribution description
RIOT image header and "riotboot" bootloader
Overview
riotbootis the name of a minimal bootloader application and infrastructure.It consists of
Concept
riotbootexpects the flash to be separated in slots: at CPU_FLASH_BASE address resides the bootloader, which is followed by a slot 0 with a firmware image.A RIOT image with a single slot looks like:
Please note that
RIOTBOOT_HDR_LENdepends on the architecture of the MCU, since it needs to be aligned to 256B. This is fixed regardless ofsizeof(riot_hdr_t).The bootloader will, on reset, verify the checksum of the first slot, then boot it. If the slot doesn't have a valid checksum, no image will be booted and the bootloader will enter
while(1);.The header contains
The bootloader "riotboot" only cares about checksum.
Testing procedure
There's a test provided in tests/riotboot. This has only tested for now in:
Please add above the boards that you have tested and worked.
Issues/PRs references
#9342
#9969