Lines Matching refs:image
48 It authenticates the firmware image by hash (SHA-256) and digital signature
50 into the bootloader image or can be provisioned to the SoC during manufacturing.
51 Metadata of the image is delivered together with the image itself in a header
53 execution to the secure image. Execution never returns to bootloader until
69 (multiple image boot) or together (single image boot). In case of multiple image
71 separately. In case of single image boot the secure and non-secure image is
76 concatenated. In case of single image boot they are concatenated first and then
77 signed. In case of multiple image boot they are separately signed first and then
91 Secure + Non-Secure image;
93 - 0x0008_0000 - 0x0008_03FF: Common image header
94 - 0x0008_0400 - 0x0008_xxxx: Secure image
96 - 0x0010_0400 - 0x0010_xxxx: Non-secure image
98 metadata of combined image
100 - 0x0018_0000 - 0x0027_FFFF: Secondary slot : Secure + Non-Secure image;
103 - 0x0028_0000 - 0x0037_FFFF: Scratch area, only used during image
106 Multiple image boot requires a slightly different layout::
109 - 0x0008_0000 - 0x000F_FFFF: Primary slot : Secure image
110 - 0x0008_0000 - 0x0008_03FF: Secure image header
111 - 0x0008_0400 - 0x000x_xxxx: Secure image
113 metadata of secure image
115 - 0x0010_0000 - 0x0017_FFFF: Primary slot : Non-secure image
116 - 0x0010_0000 - 0x0010_03FF: Non-secure image header
117 - 0x0010_0400 - 0x001x_xxxx: Non-secure image
119 metadata of non-secure image
121 - 0x0018_0000 - 0x001F_FFFF: Secondary slot : Secure image
122 - 0x0020_0000 - 0x0027_FFFF: Secondary slot : Non-secure image
124 - 0x0028_0000 - 0x002F_FFFF: Scratch area, only used during image
126 image as well
135 executed-in-place (XIP). The default behaviour is the overwrite-based image
138 the new firmware image, the content of the primary slot must be overwritten with
139 the content of the secondary slot (the new firmware image). The second option is
140 the image swapping strategy when the content of the two memory slots must be
143 eliminates the complexity of image swapping and its administration. Active image
149 Active image is stored in the primary slot, and this image is started always by
151 bootloader finds a valid image in the secondary slot, which is marked for
153 the content of the secondary slot, before starting the new image from the
155 overwritten, the header and trailer of the new image in the secondary slot is
156 erased to prevent the triggering of another unnecessary image upgrade after a
164 switch (see `Build time configuration`_). With swapping image upgrade strategy
165 the active image is also stored in the primary slot and it will always be
166 started by the bootloader. If the bootloader finds a valid image in the
168 and the secondary slot will be swapped, before starting the new image from the
169 primary slot. Scratch area is used as a temporary storage place during image
179 After a successful image upgrade, user can mark the image as "OK"
185 whether the image is acceptable. Therefore the bootloader will always
192 then the active image flag is moved between slots during firmware upgrade. If
196 new image, must be aware, which slot hosts the active firmware and which acts as
197 a staging area and it is responsible for downloading the proper firmware image.
198 At boot time MCUBoot inspects the version number in the image header and passes
199 execution to the newer firmware version. New image must be marked for upgrade
201 verification is done the same way in all operational modes. If new image fails
203 image, after successful authentication.
205 To select which slot the image is to be executed from, set
212 Only single image boot is supported with direct-xip upgrade mode.
216 Musca-S supports an image upgrade mode that is separate to the other (overwrite,
218 to the table below). Like the direct-xip mode, this selects the newest image
219 by reading the image version numbers in the image headers, but instead of
220 executing it in place, the newest image is copied to RAM for execution. The load
221 address, the location in RAM where the image is copied to, is stored in the
222 image header.
224 Summary of different modes for image upgrade
226 Different implementations of the image upgrade operation (whether through
277 .. [3] The image executes in-place (XIP) and is in Overwrite mode for image
294 Multiple image boot
298 Multiple image boot is supported only together with the overwrite and swap
303 These dependencies are part of the image manifest area.
306 - **Image identifier:** The number of the image which the current image (whose
307 manifest area contains the dependency entry) depends on. The image identifier
310 - **Minimum version:** The minimum version of other image must be present on
317 - ``MCUBOOT_S_IMAGE_MIN_VER`` It is added to the non-secure image and specifies the
318 minimum required version of the secure image.
319 - ``MCUBOOT_NS_IMAGE_MIN_VER`` It is added to the secure image and specifies the
320 minimum required version of the non-secure image.
322 Example of how to provide the secure image minimum version::
337 - ``root-RSA-2048.pem`` : Used to sign single image (S+NS) or secure image
338 in case of multiple image boot
339 - ``root-RSA-2048_1.pem`` : Used to sign non-secure image in case of multiple
340 image boot
341 - ``root-RSA-3072.pem`` : Used to sign single image (S+NS) or secure image
342 in case of multiple image boot
343 - ``root-RSA-3072_1.pem`` : Used to sign non-secure image in case of multiple
344 image boot
354 - **False:** TF-M built without bootloader. Secure image linked to the
366 the latest image is copied to RAM and runs from there instead of being
374 - **1:** Single image boot, secure and non-secure images are signed and
376 - **2:** Multiple image boot, secure and non-secure images are signed and
379 - **True:** The hash of public key is provisioned to the SoC and the image
387 image manifest contains only the hash of the public key (imgtool uses
390 and compare against the retrieved key-hash from the image manifest. After
391 this the bootloader can verify that the image was signed with a private
398 neither the code nor the image metadata needs to contain any public
399 key data. During image validation only a key ID is passed to the verifier
420 - **True:** Adds encrypted image support in the source and encrypts the
421 resulting image using the ``enc-rsa2048-pub.pem`` key found in the MCUBoot
423 - **False:** Doesn't add encrypted image support and doesn't encrypt the
424 image.
429 already have an image on them with MCUBoot that has been compiled with
431 an encrypted image to such boards, an upgrade needs to be executed. This
432 can be done by using MCUBoot, putting an image in the secondary image
435 ``SWAP_USING_SCRATCH`` or ``SWAP_USING_MOVE``, an image is needed in
436 the primary image area as well, to trigger the update.
444 An image version number is written to its header by one of the Python scripts,
446 the RAM loading mode is enabled. It is also used in case of multiple image boot
447 when the bootloader checks the image dependencies if any have been added to the
450 The version number of the image (single image boot) can manually be passed in
456 where the missing numbers are automatically set to zero. The image version
458 the image(s) being built in the same directory will automatically change. In
462 and then an image version number is provided for the first time, the new number
463 will take precedence and be used instead. All subsequent image versions are
466 the previous one: 0.0.0+1 -> 0.0.0+2. Note: To re-apply automatic image
467 versioning, please start a clean build without specifying the image version
468 number at all. In case of multiple image boot there are separate compile time
474 Each signed image contains a security counter in its manifest. It is used by the
475 bootloader and its aim is to have an independent (from the image version)
476 counter to ensure rollback protection by comparing the new image's security
477 counter against the original (currently active) image's security counter during
478 the image upgrade process. It is added to the manifest (to the TLV area that is
479 appended to the end of the image) by one of the Python scripts when signing the
480 image. The value of the security counter is security critical data and it is in
481 the integrity protected part of the image. The last valid security counter
484 current image version. The value of the security counter (single image boot) can
489 The security counter can be independent from the image version, but not
492 from the image version number (not including the build number) and this value
493 will be added to the signed image. In case of multiple image boot there are
497 counter values will be derived from the corresponding image version similar to
498 the single image boot.
503 Normally the build system handles the signing (computing hash over the image
509 information about the mandatory and optional arguments. The tool takes an image
511 expecting. In case of single image boot after a successful build the
513 images) must be passed to the script and in case of multiple image boot the
517 Signing the secure image manually in case of multiple image boot
537 As downloading the new firmware image is out of scope for MCUBoot, the update
538 process is started from a state where the original and the new image are already
545 (single image boot), but with two different build configurations: default and
595 [INF] Jumping to the first image slot
596 [Sec Thread] Secure image initializing!
602 To update the secure and non-secure images separately (multiple image boot),
604 configuration value) and follow the same instructions as in case of single image
620 IMAGE2FILE: \Software\tfm_ss1.bin ; TF-M regression test secure (signed) image
622 IMAGE3FILE: \Software\tfm_nss1.bin ; TF-M regression test non-secure (signed) image
642 [INF] Jumping to the first image slot
643 [Sec Thread] Secure image initializing!
658 - Set the ``MCUBOOT_IMAGE_NUMBER`` compile time switch to "1" (single image
659 boot) or "2" (multiple image boot) before build.
661 During single image boot the following message will be shown in case of
673 [INF] Jumping to the first image slot
674 [Sec Thread] Secure image initializing!
688 - Make sure the image version number was increased between the two build runs
731 combined image using ``srec_cat``:
742 notice that image with higher version number (``version=1.2.3.5``) is executed:
749 [INF] Booting image from the secondary slot
751 [INF] Jumping to the first image slot
752 [Sec Thread] Secure image initializing!
782 a destination load address in RAM where the image can be copied to and executed
784 dependent files, and if multiple image boot is enabled then
792 combined image using ``srec_cat``:
803 RAM loading is enabled, notice that image with higher version number
812 [INF] Booting image from SRAM at address 0xA0020000
814 [INF] Jumping to the first image slot
815 [Sec Thread] Secure image initializing!
823 bootutil_misc.c to control the image status.
825 - Call ``boot_set_pending_multi()`` to make the image as a candidate image for
827 - Call ``boot_set_confirmed_multi()`` to make the image as a permanent image.
831 information of which slot contains the running image from the bootloader.
833 image. As a result, the firmware update service is not supported in