Update mbed-os version, update mcuboot version, add NUCLEO_L452RE_P support

Author: multiplemonomials

.gitmodules

@@ -3,4 +3,4 @@
 	url = https://github.com/mbed-ce/mbed-os.git
 [submodule "mcuboot"]
 	path = mcuboot
-	url = https://github.com/multiplemonomials/mcuboot.git
+	url = https://github.com/zhiyong-ft/mcuboot.git

CMakeLists.txt

@@ -3,11 +3,14 @@ cmake_policy(VERSION 3.19)
 
 set(MBED_APP_JSON_PATH mbed_app.json5)
 
-include(mbed-os/tools/cmake/app.cmake)
+include(mbed-os/tools/cmake/mbed_toolchain_setup.cmake)
 
-add_subdirectory(mbed-os)
+project(mbed-mcuboot-bootloader
+	LANGUAGES C CXX ASM)
+
+include(mbed_project_setup)
 
-project(mbed-mcuboot-bootloader)
+add_subdirectory(mbed-os)
 
 set(MBED_MCUBOOT_BOOTLOADER_SOURCES
 	secondary_bd.cpp
@@ -23,5 +26,3 @@ target_link_libraries(${CMAKE_PROJECT_NAME}
 	mbed-storage
 	mbed-mcuboot)
 mbed_set_post_build(${CMAKE_PROJECT_NAME})
-
-mbed_finalize_build()

README.md

@@ -216,6 +216,15 @@ Once your target has been programmed, open a serial terminal to view the debug o
 
 ```
 
+#### Junk Data in Magic
+If, instead of the application running, you get output similar to this:
+```
+[INFO][MCUb]: Primary image: magic=bad, swap_type=0x1, copy_done=0x2, image_ok=0
+<snip>                                 
+[INFO][MCUb]: Boot source: none
+```
+this may be caused by data in the "magic" region that mcuboot uses near the end of each slot. mcuboot expects this region to either have a valid signature, or be erased. If you had previously flashed an application to this board that had data in this region of flash, mcuboot may conclude that this is a "bad" magic value and not boot your application. To fix this, simply use your programmer of choice (e.g. STM32CubeProgrammer or J-Flash) to mass erase your chip, then reflash the bootloader and application.
+
 ### Erasing the secondary slot
 
 By pressing the target's button (BUTTON1, if there are multiple), you will initiate erasure of the secondary slot block device in preparation for programming the update. You should see output similar to the following:
@@ -340,7 +349,7 @@ You want the entry in MEMORY called `m_text` or `m_flash` or `m_rom` -- wherever
 
 If the entry is defined in terms of `MBED_CONFIGURED_ROM_BANK` constants, this linker script has already been upgraded.  If not, and it references `MBED_APP_START` and `MBED_APP_SIZE`, or it just uses constant addresses, then this target still needs to be upgraded.
 
-Please file a PR with mbed-ce/mbed-os asking for the linker script to be updated, or, if you are feeling adventurous, you can update the linker script yourself.  Updates can be as simple as defining the text section in terms of the `MBED_CONFIGURED_ROM_BANK` constants, though there are also a number of other fixes that are useful for older linker scripts.
+Please file an issue with mbed-ce/mbed-os asking for the linker script to be updated, or, if you are feeling adventurous, you can update the linker script yourself.  Updates can be as simple as defining the text section in terms of the `MBED_CONFIGURED_ROM_BANK` constants, though there are also a number of other fixes that are useful for older linker scripts.
 
 ### Setting Up Bootloader mbed_app.json
 
@@ -388,7 +397,7 @@ Now, you can flash the bootloader to your device using the steps above.  Make su
 ```
 
 ### Setting Up Application mbed_app.json
-Now we can set up the demo app.  Its mbed_app.json should look the same as the bootloader, *except* the `target.memory_bank_config` section.  We want this application to go into the application region of the primary slot. So, we must set the start address to `mcuboot.primary-slot-address` + `mcuboot.header-size` (which defaults to 0x1000).  Meanwhile, the size should be set to extend to the end of the primary slot (yes there are some TLVs after there, but the image tool will warn if there isn't enough space).
+Now we can set up the demo app.  Its mbed_app.json section for your target should look the same as the bootloader, *except* the `target.memory_bank_config` section.  We want this application to go into the application region of the primary slot. So, we must set the start address to `mcuboot.primary-slot-address` + `mcuboot.header-size` (which defaults to 0x1000).  Meanwhile, the size should be set to extend to the end of the primary slot (yes there are some TLVs after there, but the image tool will warn if there isn't enough space).
 
 So we'd add the following block:
 ```js

assets/generic-memory-diagram.png

@@ -17,8 +17,9 @@
         "*": {
             "platform.stdio-baud-rate": 115200,
             "target.c_lib": "small",
+            "target.application-profile": "bare-metal",
             "mcuboot.log-enable": true,
-            "mcuboot.log-level": "MCUBOOT_LOG_LEVEL_INFO", // Change DEBUG to INFO for debug prints
+            "mcuboot.log-level": "MCUBOOT_LOG_LEVEL_INFO", // Change INFO to DEBUG for debug prints
             "mbed-trace.enable": true,
             "mbed-trace.max-level": "TRACE_LEVEL_DEBUG",
             "mbed-trace.fea-ipv6": false,
@@ -149,6 +150,32 @@
             "mcuboot.scratch-size": "0x40000",
             "mcuboot.max-img-sectors": "0x180",
             "mcuboot.read-granularity": 1
+        },
+
+        "NUCLEO_L452RE_P": {
+            // Configure bootloader to live in the first 128k of flash
+            "target.memory_bank_config": {
+                "IROM1": {
+                    "size": 0x20000
+                }
+            },
+
+            // Sector size is 2k, make the scratch region use the last 8k of flash so it uses 4 sectors
+            "mcuboot.scratch-address": 0x0807E000,
+            "mcuboot.scratch-size": 0x2000,
+
+            // Primary and secondary slot need to fit in the remaining 376k of flash (512k total - 128k - 8k)
+            "mcuboot.slot-size": 0x2F000, // 188kiB
+
+            // Primary slot starts right after the bootloader
+            "mcuboot.primary-slot-address": 0x08020000,
+
+            "mcuboot.max-img-sectors": 94, // 94 flash sectors per slot
+            "mcuboot.flash-block-size": 8, // Flash program size is 8
+
+            // Since STM32 nucleo boards have no external block device, keep everything in the MCU flash.
+            "app.secondary-slot-in-flash": true,
+            "app.secondary-slot-flash-start-addr": 0x0804F000 // primary-slot-address + slot-size
         }
     }
 }