How could I create image that will be signed that mcuboot will recognise it as valid image.
I wuild like to sign image with imgtool.py in ninja script after build (target all) was succesfull.

Thanks in advance!

Robert

On Wed, Aug 22, 2018 at 01:46:18AM -0700, robert.konc@controlmatik.eu wrote:

How could I create image that will be signed that mcuboot will recognise it as
valid image.
I wuild like to sign image with imgtool.py in ninja script after build (target
all) was succesfull.

This seems to have gone unanswered.

For my use, I've always had an "outer" makefile that invokved the
cmake and ninja build on the Zephyr target (as well as mcuboot), and
then used imgtool.py and possibly assemble.py to make my resulting
image.

This probably could be added to the Zephyr build, at least the signing
part, but solving the multi-image build is possibly more an area for
something like West to solve.

This will become even more of an issue with multiple images beyond
just the bootloader, such as multiple CPUs or a trusted execution
environment (TF-M style).

David

On Fri, Mar 1, 2019 at 9:12 AM David Brown <david.brown@linaro.org> wrote:

On Wed, Aug 22, 2018 at 01:46:18AM -0700, robert.konc@controlmatik.eu wrote:

How could I create image that will be signed that mcuboot will recognise it as
valid image.
I wuild like to sign image with imgtool.py in ninja script after build (target
all) was succesfull.

This seems to have gone unanswered.

I somehow have trouble believing the date stamp on the original email.
Clogged internet pipes, perhaps.

For my use, I've always had an "outer" makefile that invokved the
cmake and ninja build on the Zephyr target (as well as mcuboot), and
then used imgtool.py and possibly assemble.py to make my resulting
image.

This probably could be added to the Zephyr build, at least the signing
part, but solving the multi-image build is possibly more an area for
something like West to solve.

Multi-image build is a build system issue, not a west issue. Nordic is
working on this, for reference:

https://github.com/zephyrproject-rtos/zephyr/compare/master...hakonfam:mulit_image_mcuboot_support

Also just FYI, west already supports building, signing, and flashing
MCUboot images. For example:

# Build and flash MCUboot itself for reel_board
west build -b reel_board -s mcuboot/boot/zephyr/ -d build-mcuboot
west flash -d build-mcuboot/

# Build and flash hello_world as an MCUboot chain-loadable image
west build -b reel_board -s zephyr/samples/hello_world/ -d build-hello
-- -DCONFIG_BOOTLOADER_MCUBOOT=y
west sign -t imgtool -d build-hello/ -- --key mcuboot/root-rsa-2048.pem
west flash --hex-file zephyr.signed.hex -d build-hello/

The above assumes your runner prefers flashing .hex files, which is
true of nrfjprog and pyocd at least. You can do it with .bin files too
but it's a little more annoying and I'd like to deprecate some of the
command line flags.

The value of "west sign -t imgtool" compared to using imgtool directly
is that it pulls the values for the --align, --header-size, and
--slot-size options out of the build directory by inspecting Kconfig
and device tree output files.

This will become even more of an issue with multiple images beyond
just the bootloader, such as multiple CPUs or a trusted execution
environment (TF-M style).

Hopefully something like the above can continue working in these
contexts, suitably extended if necessary.

Thanks,
Marti

David