Update Mbed OS CMake build file for Mbed CE #2152

multiplemonomials · 2024-12-18T07:07:21Z

Hi, I'm Jamie, maintainer of Mbed CE, the community fork of Mbed. As Mbed OS 6 has been end-of-lifed by ARM, we hope to keep support for the OS alive in our fork for a long time coming!

Several members of the project have expressed interest in getting mcuboot running with Mbed CE, so I took some time and put together a test project based off of George Beckstein's original work. I was able to get it working more or less out of the box, but I did have to make some build system changes to get things running.

In particular, I wasn't happy with how the original design required running manual commands after compiling the code. That was an unfortunate necessity with the original Mbed 5/6 build system, but with Mbed CE, we use standard CMake, so we can improve this situation! I added a CMake script which automates calling imgtool to generate initial images, update images, and the public key file needed to build the bootloader.

With these changes, I am able to get a rudimentary demo application booting and updating. I and the others on the mbed-ce project (including @lefebvresam and @zhiyong-ft) hope to test out (and document) more features in time!

On another note, we heard from this issue that there is discussion about removing the Mbed port of mcuboot. We at mbed-ce are happy to help maintain and test the port going forward, and really want it to stay in the main branch of mcuboot!

Compatibility note: This PR will maintain compatibility with Mbed OS 6 using the Mbed CLI build system and/or Mbed Studio. However, it will break compatibility with the Mbed CLI 2 CMake-based build system. This build system never really reached maturity before ARM Mbed shut down, so I doubt that too many people will be using it who do not use Mbed CE.

multiplemonomials · 2024-12-18T07:08:14Z

boot/bootutil/src/swap_scratch.c

@@ -174,6 +174,13 @@ boot_slots_compatible(struct boot_loader_state *state)
    j = sz1 = secondary_slot_sz = 0;
    smaller = 0;
    while (i < num_sectors_primary || j < num_sectors_secondary) {
+        // Make sure that the boot_img_sector_size() calls below don't access undefined memory.


I ran into a rather nasty issue when testing where I didn't set BOOT_MAX_IMG_SECTORS large enough, so this for loop exhibited undefined behavior. Throwing in a check against this.

this doesn't even make sense, this is already checked on line 156 above

Hmm, I checked in the debugger, and if I set BOOT_MAX_IMG_SECTORS to 1000, on a device that uses 1536, I see:
.

Looking into it a bit more, it seems this may be an issue due to the Mbed version of flash_area_get_sectors() never returning a count value greater than MCUBOOT_MAX_IMG_SECTORS. That causes the existing warning (which I totally didn't notice X_X) to never trigger.

ok pushed a fix!

nordicjm · 2024-12-18T08:53:04Z

boot/bootutil/src/swap_scratch.c

@@ -174,6 +174,13 @@ boot_slots_compatible(struct boot_loader_state *state)
    j = sz1 = secondary_slot_sz = 0;
    smaller = 0;
    while (i < num_sectors_primary || j < num_sectors_secondary) {
+        // Make sure that the boot_img_sector_size() calls below don't access undefined memory.


this doesn't even make sense, this is already checked on line 156 above

nordicjm · 2024-12-18T08:53:17Z

boot/bootutil/src/swap_scratch.c

+        // Make sure that the boot_img_sector_size() calls below don't access undefined memory.
+        if(i >= BOOT_MAX_IMG_SECTORS || j >= BOOT_MAX_IMG_SECTORS)
+        {
+            BOOT_LOG_WRN("Cannot upgrade: BOOT_MAX_IMG_SECTORS too small");


nordicjm

changes need to be squashed

boot/mbed/CMakeLists.txt

nordicjm · 2024-12-18T10:01:35Z