-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
west: bootloader integration for MCUboot #12903
Conversation
Codecov Report
@@ Coverage Diff @@
## master #12903 +/- ##
==========================================
+ Coverage 48.62% 48.78% +0.15%
==========================================
Files 313 313
Lines 46484 46484
Branches 10728 10728
==========================================
+ Hits 22604 22678 +74
+ Misses 19413 19310 -103
- Partials 4467 4496 +29
Continue to review full report at Codecov.
|
At a glance, this looks reasonable. I'm sure you would appreciate being aware that there exists a prototype that solves the same problem, but from CMake instead of from west. There, to get exactly the same flash contents as demonstrated above you do:
But of course, this requires a big overhaul, and is therefore taking some time to get ready for merging: master...hakonfam:mulit_image_mcuboot_support As discussed a while back, this is not a problem, as by-design and agreement we will have duplicated features across west and CMake. |
I've removed the DNM now that the dependency is merged -- @carlescufi @tejlmand mind taking a look?
I do appreciate it! Thank you for letting me know. Perhaps we have an opportunity to collaborate by bringing mcuboot in as a west project in the zephyr manifest and sharing the codebase. |
I haven't reviewed this yet, but I have a comment after a quick chat with @nashif. Doesn't |
I thought about that. The answer for now is "no", because this relies on code in the runners package to do build system inspection, which cannot be easily or cleanly imported from an extension command in another Long term if we split some of this code into a |
30d1bfb
to
2566105
Compare
I'd also say no. imgtool is a script that is run on the Zephyr application, it modifies the application such that it can be booted by MCUBoot, just like CONFIG_BOOTLOADER_MCUBOOT does: https://github.com/zephyrproject-rtos/zephyr/blob/master/Kconfig.zephyr#L342 |
This is a prep work patch for adding another command. Refactor build.py to use a new Forceable superclass and find_build_dir() helper routine. Fix a help string while we are here. Signed-off-by: Marti Bolivar <[email protected]>
Pull out some more common functionality we will need elsewhere into a separate file. Signed-off-by: Marti Bolivar <[email protected]>
This command is useful for signing binaries for loading by a bootloader. At present, only MCUboot's "imgtool" is supported, but it would be straightforward to add support for additional tools. Using this command instead of "plain" imgtool avoids looking up any numbers for the flash write block size, text section offset, or slot size to get a signed binary. All users need to specify is the location of the signing key. This greatly improves usability for those unfamiliar with MCUboot, or even experienced users who have to deal with multiple flash partition layouts, boards, etc. The command works by inspecting state in the Zephyr build system, some of which is also provided by the runner package. Signed-off-by: Marti Bolivar <[email protected]>
2566105
to
b02f5d0
Compare
@nashif @carlescufi please take a look again? As discussed elsewhere, I made this a generic command which takes a backend tool as argument. It should be suitable for extension with additional backends, such as the nrf tooling for the non-mcuboot bootloader. Here is the updated usage showing how it works now:
|
@mbolivar |
bflash -> (background Linux bash script implementation just for e.g.)
|
@hakonfam @SebastianBoe could you please re-review this one? It's been made more generic by renaming the command |
@Vikrant8051 Flashing the bootloader + signed hex is an interesting idea but ultimately I think this might be pushing it at this point, because the west commands today only deal with the current build, which corresponds to the app, since it parses the CMakeCache in a build folder to achieve that. |
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.
LGTM in the current state
@Vikrant8051 I agree but we need to wait to put the mcuboot repository into the west manifest to really get that done. Let's start here for LTS and make it better during the next development cycle? You may also be interested in the work that @SebastianBoe is working on: master...hakonfam:mulit_image_mcuboot_support |
@mbolivar sure !! |
Great, thanks! |
@mbolivar I also tried ... but no success. Error:
|
pip3 install imgtool
|
@SebastianBoe Thanks for such prompt response. Now I can do that. |
This pull request makes it significantly easier for users to build Zephyr applications as signed MCUboot payloads. The main addition is a new extension command,
imgtool-sign
. The rest is just moving code around.Assuming that there is an MCUboot repository in
~/src/mcuboot
, this series makes it possible to build and flash MCUboot itself, as well as Zephyr'shello_world
app as an MCUboot signed image, with the following commands (fornrf52840_pca10056
, though other boards should work as well):If doing this for the first time, it's smart to completely erase the flash on the chip, e.g. with
nrfjprog --eraseall
.