search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.73k stars 6.55k forks source link

disco_l475_iot1 don't confirm MCUBoot slot-1 image #25010

Closed nandojve closed 3 years ago

nandojve commented 4 years ago

Describe the bug When build UpdateHub for disco_l475_iot1 the app don't confirm the image.

To Reproduce Steps to reproduce the behavior:

  1. clone https://github.com/UpdateHub/zephyr/commits/topic/uhu_wifi
  2. set variables at prj.conf CONFIG_UPDATEHUB_WIFI_SSID="wifi network" CONFIG_UPDATEHUB_WIFI_PSK="password"
  3. west build -b disco_l475_iot1 samples/net/updatehub
  4. sign image ~//bootloader/mcuboot/scripts/imgtool.py sign --key ~//bootloader/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.0.0 --slot-size 0x6C000 ~//zephyr/build/zephyr/zephyr.hex ~//zephyr/build/zephyr/zephyr-1.0.0.hex
  5. west flash --hex-file build/zephyr/zephyr-1.0.0.hex
  6. See error

Expected behavior _boot_write_imgconfirmed() executes properly on main.c

Impact MCUBoot applications don't work.

Screenshots or console output

*** Booting Zephyr OS build zephyr-v2.2.0-2058-g1e3fd042505e  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.007,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.007,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.007,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none

uart:~$ *** Booting Zephyr OS build zephyr-v2.2.0-2358-gf071c82bc516  ***

[00:00:00.539,000] <inf> main: UpdateHub sample app started
[00:00:00.539,000] <inf> main: Confirming the boot image
[00:00:00.539,000] <err> main: Error to confirm the image  <<<<<<< PROBLEM
uart:~$ Connected <<< WIFI got connected >>>>
*** Booting Zephyr OS build zephyr-v2.2.0-2058-g1e3fd042505e  *** <<<<< AUTO REBOOT
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.007,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.007,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.007,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none

Environment (please complete the following information):

nandojve commented 4 years ago

CC @otavio @erwango

erwango commented 4 years ago

^^@ABOSTM

parthitce commented 4 years ago

@nandojve Is this TLS enabled?

nandojve commented 4 years ago

Hi @parthitce, if you are referring to UpdateHub, yes, it works with/without DTLS. Take look at https://github.com/zephyrproject-rtos/zephyr/tree/master/lib/updatehub and https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/updatehub. You can get more info at https://updatehub.io/

About MCUBoot, you must use your own certificate to sign images. https://github.com/JuulLabs-OSS/mcuboot/blob/master/docs/readme-zephyr.md

To get MCUboot working you need SoC flash stuff working properly, as far I know. With that, you can get UpdateHub working if you have a network interface. You can use a wifi shield like ESP_8266 or any other available. The shield is basically wifi config + board overlay. https://github.com/zephyrproject-rtos/zephyr/tree/master/boards/shields/esp_8266

This way, you don't need a full ethernet available to test it, only a serial 115200 with RX/TX.

ABOSTM commented 4 years ago

Hi @nandojve, It would be interresting to determined whether issue comes from wifi as opposed to ethernet. So I tried to run the samples\net\updatehub\ from original zephyr on STM32F429 which support Ethernet. I followed instructions from samples\net\updatehub\README.rst Unfortunately after spending about 1 day and a half, I am unable to have updateHub image running with docker.

$ docker run -i -p 8080:8080 -p 5683:5683/udp --rm updatehub/updatehub-ce:latest Unable to find image 'updatehub/updatehub-ce:latest' locally C:\Program Files\Docker\Docker\resources\bin\docker.exe: Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers).

I suspect Proxy issue, I tried to set proxy environnement variables, and also tried to add proxy to config.json, but it doesn't help.

I looked for precompiled updateHub image for windows to download, (so that it could be available locally) but I could not found it. I also tried to recompile it, but I face again connection issue when installing Packr utility:

$ go get -u github.com/gobuffalo/packr/packr go: github.com/BurntSushi/toml@v0.3.1: Get "https://proxy.golang.org/github.com/%21burnt%21sushi/toml/@v/v0.3.1.mod": dial tcp [2a00:1450:4007:816::2011]:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Would you be able to test on your side the same: From original Zephyr repo, on any STM32 board with Ethernet (instead of Wifi) ?

nandojve commented 4 years ago

Hi @ABOSTM,

Docker procedures:

docker pull updatehub/updatehub-ce
# get container_id if updatehub docker is running
docker ps
docker stop container_id
# run       local-port:docker-port
docker run -it -p 8081:8080 -p 5683:5683/udp --rm updatehub/updatehub-ce:latest
# How to access (localhost == CONFIG_UPDATEHUB_SERVER)
http://localhost:8081/
# login admin
# pass admin

Current master need update timer variable because timer changes, we'll open issue and send PR:

diff --git a/lib/updatehub/updatehub.c b/lib/updatehub/updatehub.c
index e50b4503cf..a61450f7f3 100644
--- a/lib/updatehub/updatehub.c
+++ b/lib/updatehub/updatehub.c
@@ -32,7 +32,7 @@ LOG_MODULE_REGISTER(updatehub);
 #include <net/tls_credentials.h>
 #endif

-#define NETWORK_TIMEOUT K_SECONDS(2)
+#define NETWORK_TIMEOUT 2000
 #define UPDATEHUB_POLL_INTERVAL K_MINUTES(CONFIG_UPDATEHUB_POLL_INTERVAL)
 #define MAX_PATH_SIZE 255
 /* MAX_PAYLOAD_SIZE must reflect size COAP_BLOCK_x option */

Update prj.conf file for convenience:

diff --git a/samples/net/updatehub/prj.conf b/samples/net/updatehub/prj.conf
index 603ea45e41..776ed4b05b 100644
--- a/samples/net/updatehub/prj.conf
+++ b/samples/net/updatehub/prj.conf
@@ -18,3 +18,10 @@ CONFIG_UPDATEHUB_SHELL=y
 # Debug helpers
 CONFIG_LOG=y
 CONFIG_UPDATEHUB_LOG_LEVEL_INF=y
+
+#Example of product_uid, you must set you product uid.
+CONFIG_UPDATEHUB_PRODUCT_UID="e4d37cfe6ec48a2d069cc0bbb8b078677e9a0d8df3a027c4d8ea131130c4265f"
+CONFIG_UPDATEHUB_POLL_INTERVAL=1
+CONFIG_UPDATEHUB_CE=y
+# Local network IP, the machine that will run docker
+CONFIG_UPDATEHUB_SERVER="192.168.10.199"

Build for frdm_k64f board

# Just to make sure everything is on good shape
rm -rf build
rm -rf .uhu

# build
west build -b frdm_k64f samples/net/updatehub

# sign image that you will flash using JTAG, for instance:
~/zephyros/mainline/bootloader/mcuboot/scripts/imgtool.py sign --key ~/zephyros/mainline/bootloader/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.0.0 --slot-size 0x60000 /home/gfbudke/zephyros/mainline/zephyr/build/zephyr/zephyr.bin /home/gfbudke/zephyros/mainline/zephyr/build/zephyr/zephyr-1.0.0.bin

# sign image that you will use to upgrade using UpdateHub:
~/zephyros/mainline/bootloader/mcuboot/scripts/imgtool.py sign --key ~/zephyros/mainline/bootloader/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 2.0.0 --slot-size 0x60000 /home/gfbudke/zephyros/mainline/zephyr/build/zephyr/zephyr.bin /home/gfbudke/zephyros/mainline/zephyr/build/zephyr/zephyr-2.0.0.bin

# note: for frdm_k64f --slot-size is 0x60000, check flash slot partition:
# for disco_l475_iot1.dts
#       slot0_partition: partition@20000 {
#           label = "image-0";
#           reg = <0x00020000 0x0006C000>;
#       };

# create uhu pakage:
# CONFIG_UPDATEHUB_PRODUCT_UID from prj.conf
uhu product use "e4d37cfe6ec48a2d069cc0bbb8b078677e9a0d8df3a027c4d8ea131130c4265f"

# make sure put full relative path (build/zephyr):
uhu package add build/zephyr/zephyr-2.0.0.bin -m zephyr

# set package version
uhu package version 2.0.0

# you can use other output dir
uhu package archive --output build/zephyr/zephyr-2.0.0.pkg

Flash initial image: west flash --bin-file build/zephyr/zephyr-1.0.0.bin

Server not found, no network, etc:

uart:~$ updatehub run 
Starting UpdateHub run...
Invalid response
[00:01:38.354,000] <err> updatehub: Could not receive data
uart:~$

OK, now run docker container and login: docker run -it -p 8081:8080 -p 5683:5683/udp --rm updatehub/updatehub-ce:latest

Server running and communication is OK:

uart:~$ updatehub run
Starting UpdateHub run...
No update found
[00:02:03.067,000] <inf> updatehub: No update available

Check that machine is connected at devices:

Setup update: Use UpdateHub CE web interface to upload build/zephyr/zephyr-2.0.0.pkg at packages

Program a upload: Goto rollouts and create a new one:

Wait or force upload at board's terminal:

uart:~$ updatehub run 
Starting UpdateHub run...
[00:01:18.844,000] <inf> updatehub: Probe metadata received
[00:01:20.353,000] <inf> updatehub: Firmware downloaded successfully
[00:01:20.391,000] <inf> updatehub: Image flashed successfully, you can reboot now
uart:~$ kernel reboot cold *** Booting Zephyr OS build zephyr-v2.2.0-2058-gc2f118723970  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: none
[00:00:00.006,000] <inf> mcuboot: Swap type: test
*** Booting Zephyr OS build v2.3.0-rc1  ***

uart:~$ updatehub info 
Unique device id: ffffffff4e454130000b000f
Firmware Version: 2.0.0
Product uid: e4d37cfe6ec48a2d069cc0bbb8b078677e9a0d8df3a027c4d8ea131130c4265f
UpdateHub Server: 192.168.10.199
[00:00:03.000,000] <inf> eth_mcux: ETH_0 enabled 100M full-duplex mode.
uart:~$

If you have network running and flash works with MCUboot you will be able to reproduce above steps. If you have any trouble, please, let me know!

carlescufi commented 4 years ago

@nvlsianpu is this related to the confirmation bug in mcumgr that you detected the other day?

nvlsianpu commented 4 years ago

@carlescufi ^^ not related to that one (was issue caused by different NCS partition manager configuration).

@nandojve Is this bug is regression to something which used to work before, or it was newer tested on this SoC? Confirmation problems suggest me an issue with the flash write operation to write area, as confirmation is just the write of proper data to certain flash addresses.

ABOSTM commented 4 years ago

Hi @nandojve , After you provided me the package I could not generate, I continued on Ethernet use case on nucleo_f429zi. I finally get IP address with DHCP (I had issue with my PLC to connect to my internet box) But unfortunately I spent a lot of time and I am stuck again: my updateHub server is accessible from web browser running on the same PC running the server, but the server is not accessible from another PC even if running on the same local network. In other word, updatehub server is isolated and cannot be accessible by any external device.

As I understand, generally speaking, updatehub is working with ESP_8266 shield. Would it be possible for you to test updateHub disco_l475_iot1 with this ESP shield on ? (Deactivating disco_l475_iot1 wifi module, and enabling ESP shield)

nandojve commented 4 years ago

Hi @ABOSTM, by the docker command line you must have UDP port 5683 open to work. If for some reason this port is blocked you can't communicate with docker service.

Anyway, my problem to advance with disco_iot is related to the logs:

[00:00:00.539,000] <inf> main: Confirming the boot image
[00:00:00.539,000] <err> main: Error to confirm the image  <<<<<<< PROBLEM
uart:~$ Connected <<< WIFI got connected >>>>

That message is printed by the following code at samples/net/updatehub/main.c

    /* The image of application needed be confirmed */
    LOG_INF("Confirming the boot image");
    ret = boot_write_img_confirmed();
    if (ret < 0) {
        LOG_ERR("Error to confirm the image");
    }

So, my problem is, boot_write_img_confirmed need be OK to system work. It seems something related to flash on disco_iot. This issue you can check without UpdateHub-CE be present. Be sure trhat NET_CONFIG_SETTINGS option is false. Depending the code you are looking my be necessary adjust it on zephyr/lib/updatehub/Kconfig.

https://github.com/UpdateHub/zephyr/commit/6db1c5a874e9bedf6cffe6d5b93ebd60cd6dcc8e

About WIFI, I have both es-WIFI and ESP_8266 working, so yes, I can test and switch if necessary.

ABOSTM commented 4 years ago

Hi @nandojve , I intend to put a debugger to understand why boot_write_img_confirmed() return is not OK, to know which step fails with which error code ... This is why I tried to get updateHub up and running. If you know a way to reproduce the issue without the server, please let me know . For example, would it be possible to flash the update image ( which one exactly?? including probably the necessary header describing the image ...) to the flash, so that I could be in the same state than after updateHub would have written flash with the update image? and thus be able to reproduce the issue. This suppose writting the update image was fully successful ..

nandojve commented 4 years ago

@nandojve Is this bug is regression to something which used to work before, or it was newer tested on this SoC? Confirmation problems suggest me an issue with the flash write operation to write area, as confirmation is just the write of proper data to certain flash addresses.

@nvlsianpu I never got UpdateHub working on that board. I've been raising issues related with hope to get disco_iot working at some moment. My feeling is that solving the boot_write_img_confirmed (this issue) and assuming flash write is OK probably UpdateHub will start to works.

nandojve commented 4 years ago

Hi @nandojve , I intend to put a debugger to understand why boot_write_img_confirmed() return is not OK, to know which step fails with which error code ... This is why I tried to get updateHub up and running. If you know a way to reproduce the issue without the server, please let me know . For example, would it be possible to flash the update image ( which one exactly?? including probably the necessary header describing the image ...) to the flash, so that I could be in the same state than after updateHub would have written flash with the update image? and thus be able to reproduce the issue. This suppose writting the update image was fully successful ..

@ABOSTM it is mandatory apps confirm the image on first boot otherwise MCUBoot will must roolback on next reboot. I think this is not fully addressed on current MCUBoot samples on Zephyr. The consequence is we can't see regressions or even know that MCUBoot is 100% functional and supported.

My suggestion is add boot_write_img_confirmed at hello word targeting to MCUBoot (CONFIG_BOOTLOADER_MCUBOOT=y) and debug it. If boot_write_img_confirmed fail you can experiment board enter on a infinite reset loop because there isn't a plan B image. Take that on consideration because isn't a bug.

@nvlsianpu Is there a regression test to check boot_write_img_confirmed requirement?

ABOSTM commented 4 years ago

@nandojve , Following your proposal, I test disco_l475_iot1 , I erase full flash, then flash MCUBOOT, then flash Helloworld example (signed image) with call to boot_write_img_confirmed() But I did not face issue, function returns 0 wich is good:

Booting Zephyr OS build zephyr-v2.2.0-2072-g6102ba19f1ee [00:00:00.005,000] mcuboot: Starting bootloader [00:00:00.007,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x1 [00:00:00.007,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 [00:00:00.007,000] mcuboot: Boot source: primary slot [00:00:00.015,000] mcuboot: Swap type: none Booting Zephyr OS build zephyr-v2.2.0-2072-g6102ba19f1ee Hello World! disco_l475_iot1 Confirming the boot image Confirm the image return 0

nandojve commented 4 years ago

Hi @ABOSTM thank you for the feedback! Could you confirm SHA that you tested?

ABOSTM commented 4 years ago

@nandojve SHA1:5321c4288203c113abac5eab9eaca918e9b4f8f9

nandojve commented 4 years ago

@ABOSTM I continue saw flash not be confirmed on your SHA and on the last one.

The only difference that raise a flag for me was that:

Your Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x1 mine Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3

Below the procedure that I believe get last version of everything to make sure environment is not poisoned.

Please, add #25333 on top of master if not merged yet.

git checkout master
git fetch upstream
git rebase upstream/master
git lg -5
* 25a2f6c175 - (HEAD -> master) lib: updatehub: Add missing include for FLASH_AREA (34 minutes ago) <Gerson Fernando Budke>
* a0ae53410e - (upstream/master) sanitylib: Remove hardcoded sample.yaml & testcase.yaml in TestSuite class (5 hours ago) <Aastha Grover>
* 5496ea2d9b - soc: x86: apollo_lake: Fix incorrect DTS gpio nodelabel references (10 hours ago) <Kumar Gala>
* 845abb04cf - boards: qemu_xtensa: enable icount mode (14 hours ago) <Wentong Wu>
* bb80d3528e - boards: hifive1: enable icount mode (14 hours ago) <Wentong Wu>

After that, I always make sure that all modules are on the last version:

gfbudke@Capricornio:~/zephyros/mainline/zephyr$ west update
=== updating cmsis (modules/hal/cmsis):
HEAD is now at 542b229 DSP: Integrate CMSIS-DSP 1.8.0 (CMSIS 5.7.0)
=== updating hal_atmel (modules/hal/atmel):
HEAD is now at 1fe96f0 samv71: patch: Fix GMAC priority queue register offsets
=== updating hal_altera (modules/hal/altera):
HEAD is now at 23c1c1d hal_altera: Conditionally include the Altera HAL
=== updating canopennode (modules/lib/canopennode):
HEAD is now at 5c6b056 stack: remove all GNU GPL licensed platform drivers
=== updating ci-tools (tools/ci-tools):
HEAD is now at da9a2df labels: change test suite label
=== updating civetweb (modules/lib/civetweb):
HEAD is now at 99129c5e Merge pull request #778 from antmicro/zephyr-filtering
=== updating esp-idf (modules/hal/esp-idf):
HEAD is now at 6835bfc74 module: add zephyr integration
=== updating fatfs (modules/fs/fatfs):
HEAD is now at 9ee6b9b fs: Expose _USE_LFN, _MAX_LFN, and _CODE_PAGE as kconfig options.
=== updating hal_cypress (modules/hal/cypress):
HEAD is now at a12d928 zephyr: move kconfig to the zephyr tree
=== updating hal_infineon (modules/hal/infineon):
HEAD is now at f1fa824 hal: infineon: initial commit of XMCLib
=== updating hal_nordic (modules/hal/nordic):
HEAD is now at e5a1a6f nrf_radio_802154: Use chosen zephyr,entropy to get entropy device
=== updating hal_openisa (modules/hal/openisa):
HEAD is now at 3b54187 hal: openisa: pass MIC status from CAUv3 on stack
=== updating hal_microchip (modules/hal/microchip):
HEAD is now at aad89bf modules: Fix MEC1501 OOB RX/TX transfer length masks
=== updating hal_silabs (modules/hal/silabs):
HEAD is now at 78da967 hal_silabs: patch: rename ramfunc section to match Zephyr's
=== updating hal_st (modules/hal/st):
HEAD is now at 5b3ec3e hal_st: CMakelists: Update coding style to main repo
=== updating hal_stm32 (modules/hal/stm32):
HEAD is now at d1bc80d hal_stm32: rename HAS_STLIB in HAS_STM32LIB
=== updating hal_ti (modules/hal/ti):
HEAD is now at c398cc7 cc13x2_cc26x2: drivers: fix build warnings in PowerCC26X2.c
=== updating libmetal (modules/hal/libmetal):
HEAD is now at 3c3c9ec lib: update libmetal to release v2020.04.0
=== updating lvgl (modules/lib/gui/lvgl):
HEAD is now at 74fc2e75 Merge lvgl v6.1.1 into zephyr branch
=== updating mbedtls (modules/crypto/mbedtls):
HEAD is now at 8211541 config-tls-generic: Add CTR cipher mode
=== updating mcuboot (bootloader/mcuboot):
HEAD is now at e88113b scripts/assemble: Rework to use EDT library to get devicetree data
=== updating mcumgr (modules/lib/mcumgr):
HEAD is now at 1f5234c zephyr: Convert to new FLASH_AREA macros
=== updating net-tools (tools/net-tools):
HEAD is now at 1c4fdba docker: Add dante SOCKS 5 proxy
=== updating hal_nxp (modules/hal/nxp):
HEAD is now at 80a337d mcux: build LPC Entropy drivers
=== updating open-amp (modules/lib/open-amp):
HEAD is now at 724f7e2 lib: update open-amp lib to release v2020.04.0
=== updating loramac-node (modules/lib/loramac-node):
HEAD is now at 29e516ec radio: sx1276: allow overriding Buffer reand/write functions
=== updating openthread (modules/lib/openthread):
HEAD is now at a83d18cf cmake: Make sure libc is linked after OT libs
=== updating segger (modules/debug/segger):
HEAD is now at 6fcf616 ext: segger: update to SystemView v2.52h
=== updating tinycbor (modules/lib/tinycbor):
HEAD is now at 40daca9 zephyr: Remove TINYCBOR from interface libraries
=== updating tinycrypt (modules/crypto/tinycrypt):
HEAD is now at 3e9a49d cmake: Fix conditional in root CMakeLists.txt
=== updating littlefs (modules/fs/littlefs):
HEAD is now at 0aefdda Merge tag 'v2.2.0' into zephyr
=== updating mipi-sys-t (modules/debug/mipi-sys-t):
HEAD is now at 957d46b Delete initialization related code from mipi-sys-t tree
=== updating nrf_hw_models (modules/bsim_hw_models/nrf_hw_models):
HEAD is now at fec6970 Convert into a west module
=== updating hal_xtensa (modules/hal/xtensa):
HEAD is now at e7a57d0 hal: Add README for information on updating HAL versions.
=== updating edtt (tools/edtt):
HEAD is now at c39888f Update unsupported commands test to handle command status response
=== updating trusted-firmware-m (modules/tee/tfm):
HEAD is now at 7de2daa zephyr: cmake: TF-M libraries to be used by the ns-app
gfbudke@Capricornio:~/zephyros/mainline/zephyr$

Then, apply changes on hello_world

git stash pop
On branch master
Your branch is ahead of 'origin/master' by 162 commits.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   samples/hello_world/prj.conf
    modified:   samples/hello_world/src/main.c

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (0c8e0a6f0547cf8acf2ba2c81e4b9f04aefe9636)

diff:

git diff
diff --git a/samples/hello_world/prj.conf b/samples/hello_world/prj.conf
index b2a4ba5910..08ea5c1f9a 100644
--- a/samples/hello_world/prj.conf
+++ b/samples/hello_world/prj.conf
@@ -1 +1,5 @@
 # nothing here
+CONFIG_BOOTLOADER_MCUBOOT=y
+CONFIG_IMG_MANAGER=y
+CONFIG_FLASH=y
+CONFIG_MPU_ALLOW_FLASH_WRITE=y
diff --git a/samples/hello_world/src/main.c b/samples/hello_world/src/main.c
index 6c5c8a27dc..4abe9174a6 100644
--- a/samples/hello_world/src/main.c
+++ b/samples/hello_world/src/main.c
@@ -7,7 +7,22 @@
 #include <zephyr.h>
 #include <sys/printk.h>

+#include <dfu/mcuboot.h>
+
 void main(void)
 {
+       int ret = -1;
+
        printk("Hello World! %s\n", CONFIG_BOARD);
+
+       /* The image of application needed be confirmed */
+       printk("Confirming the boot image\n");
+       ret = boot_write_img_confirmed();
+       if (ret < 0) {
+               printk("Error to confirm the image\n");
+       } else {
+               printk("Image is OK\n");
+       }
+
+       for(;;);
 }

build: west build -b disco_l475_iot1 samples/hello_world

sign with --slot-size 0x6C000 ~/zephyros/mainline/bootloader/mcuboot/scripts/imgtool.py sign --key ~/zephyros/mainline/bootloader/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.0.0 --slot-size 0x6C000 /home/gfbudke/zephyros/mainline/zephyr/build/zephyr/zephyr.hex /home/gfbudke/zephyros/mainline/zephyr/build/zephyr/zephyr-1.0.0.hex

I'm using west to flash image: west flash --hex-file build/zephyr/zephyr-1.0.0.hex

Then, the unfortunately result:

*** Booting Zephyr OS build v2.3.0-rc1-102-g1383170029db  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-100-g25a2f6c175e3  ***
Hello World! disco_l475_iot1
Confirming the boot image
Error to confirm the image
ABOSTM commented 4 years ago

Hi @nandojve , I reinstalled Zephyr from scratch (e550302a61a088abe549e7bf4d3a2fd51d8971f3), I merge your modification of hello world example. I build and flash MCUBoot , then build and flash example, and again it is working fine:

*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
Hello World! disco_l475_iot1
Confirming the boot image
Image is OK

There is 1 thing you did not mention in your procedure: recompiling MCUBoot and flashing it? Did you just omite to mention it or you didn't do it? I may be worth to give it a try.

otavio commented 4 years ago

@ABOSTM is there any lower level debugging information which might help to spot what is different from your setup?

nandojve commented 4 years ago

Hi @ABOSTM

There is 1 thing you did not mention in your procedure: recompiling MCUBoot and flashing it? Did you just omite to mention it or you didn't do it? I may be worth to give it a try.

I simple omit, but I built MCUboot and flash it first same week. I'll give another try with latest.

Anyway, could you help to understand why the difference? Your version [00:00:00.006,000] mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=~0x3~ 0x1 Mine [00:00:00.006,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=~0x1~ 0x3

What make that image_ok=0x3 instead 0x1? Could be this the reason I can confirm image?

NOTE: Update comment with right flags.

ABOSTM commented 4 years ago

I am not an MCUBoot expert, but I found those definitions

#define BOOT_FLAG_SET       1
#define BOOT_FLAG_BAD       2
#define BOOT_FLAG_UNSET     3
#define BOOT_FLAG_ANY       4  /* NOTE: control only, not dependent on sector */

Then I figure out that after a fresh flashing of images, the 1st boot displays image_ok=0x3 and then all further reboots (manual reset) display image_ok=0x1 So the fact you have image_ok=0x3 is good. And It makes sense to me as the change is done by the call to boot_write_img_confirmed(), which will set image_ok=1 ... after confirmation.

Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0 [00:00:00.005,000] mcuboot: Starting bootloader [00:00:00.006,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 [00:00:00.006,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 [00:00:00.006,000] mcuboot: Boot source: primary slot [00:00:00.013,000] mcuboot: Swap type: none Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0 Hello World! disco_l475_iot1 Confirming the boot image Image is OK Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0 [00:00:00.005,000] mcuboot: Starting bootloader [00:00:00.006,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x1 [00:00:00.006,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 [00:00:00.006,000] mcuboot: Boot source: primary slot [00:00:00.013,000] mcuboot: Swap type: none Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0 Hello World! disco_l475_iot1 Confirming the boot image Image is OK

But it still doesn't explain why you are not able to confirm the image. I send you both images I generated (MCUboot and hello word application). Can you start by a fullerase of the flash (if needed you can use CubeProgrammer https://www.st.com/en/development-tools/stm32cubeprog.html) And then flash both image, It should work !!! Then you can try to mix: My MCUBoot image + Your application and then Your MCUBoot + My application It is important to make a full erase of the flash between each test.

ABOSTM commented 4 years ago

zephy_MCUBoot.zip

zephyr-1.0.0_Signed_HelloWorld.zip

nandojve commented 4 years ago

@ABOSTM , sure, I'll do! Thank you for helping.

@utzig any comment here can help a lot!

utzig commented 4 years ago

Well, it worked for me as well:

*** Booting Zephyr OS build v2.3.0-rc1-138-gc46b138453a2  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-138-gc46b138453a2  ***
Hello World! disco_l475_iot1
Confirming the boot image
Image is OK
*** Booting Zephyr OS build v2.3.0-rc1-138-gc46b138453a2  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: test
*** Booting Zephyr OS build v2.3.0-rc1-138-gc46b138453a2  ***
Hello World! disco_l475_iot1
Confirming the boot image
Image is OK

I am using latest MCUBoot and fairly recent Zephyr tree (updated this afternoon). This error you're having usually happens if you have built the bootloader and the app with partition configurations that are not the same. Otherwise I would suggest attaching a debugger at boot_write_img_confirmed to check why it is failing.

nandojve commented 4 years ago

Hi @ABOSTM,

At first, I did another try with lastest Zephyr version and your signed image, both without success. So, move to install stm32cubeprog, update st-link version from 18 to 26, first erase full + flash with error. I repeat the process and got success. Than, write my hello image using west and got the image confirmed.

*** Booting Zephyr OS build v2.3.0-rc1-138-g1d06829ef97b  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-138-g1d06829ef97b  ***
Hello World! disco_l475_iot1
Confirming the boot image
Image is OK
*** Booting Zephyr OS build v2.3.0-rc1-138-g1d06829ef97b  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-138-g1d06829ef97b  ***
Hello World! disco_l475_iot1
Confirming the boot image
Image is OK
*** Booting Zephyr OS build v2.3.0-rc1-138-g1d06829ef97b  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-138-g1d06829ef97b  ***
Hello World! disco_l475_iot1
Confirming the boot image
Image is OK

I remember that I lost the board sometimes, usully ctrl+C when using west. The west was not able to write anymore. The solution was cp *hex or bin to mounted unity and get board running again. Not sure if that can cause flash write problem.

I think we discover the way to make board works, need flash MCUboot using stm32cubeprog with full chip erase. With that, I can move forward and I think this issue can be closed.

Question: Is there a way to flash with full erase from command line on linux?

Just for record: I give some UpdateHub runs and get below:

When I put UpdateHub to run I got some connection instability and was need increase TCP/IP buffers. After some attempts I got

Using es-WIFI
[00:00:00.538,000] <inf> main: UpdateHub sample app started
[00:00:00.538,000] <inf> main: Confirming the boot image
[00:00:03.635,000] <inf> main: WIFI Connected
[00:00:03.641,000] <inf> main: Starting UpdateHub polling mode
[00:00:04.200,000] <inf> updatehub: Probe metadata received
[00:02:41.766,000] <err> flash_stm32: Write range invalid. Offset: 845824, len: 92
[00:02:41.766,000] <err> STREAM_FLASH: flash_write error -22 offset=0x000ce800
[00:02:41.766,000] <err> updatehub: Error to write on the flash

And

Using ESP_8266
[00:00:00.570,000] <inf> main: UpdateHub sample app started
[00:00:00.570,000] <inf> main: Confirming the boot image
[00:00:04.436,000] <inf> main: WIFI Connected
[00:00:04.478,000] <inf> main: Starting UpdateHub polling mode
[00:00:05.391,000] <inf> updatehub: Probe metadata received
[00:00:53.641,000] <err> flash_stm32: Write range invalid. Offset: 880640, len: 140
[00:00:53.641,000] <err> STREAM_FLASH: flash_write error -22 offset=0x000d7000
[00:00:53.641,000] <err> updatehub: Error to write on the flash
ABOSTM commented 4 years ago

Hi @nandojve , Good news !! I don't know exactly what appends in your flash, but maybe previousoperations leave some images header in the secondary slot or in scratch area which make MCUBoot confused.

Question: Is there a way to flash with full erase from command line on linux?

It is possible to use CubeProgrammer with command line (CLI). I nerver use it by you can found information in the documentation: https://www.st.com/resource/en/user_manual/dm00403500-stm32cubeprogrammer-software-description-stmicroelectronics.pdf

It think it should also be possible to use OpenOCD or PyOCD do full erase the flash. But I am not sure Zephyr propose such option.

utzig commented 4 years ago

I don't know exactly what appends in your flash, but maybe previousoperations leave some images header in the secondary slot or in scratch area which make MCUBoot confused.

Confirming does actually write the confirmed flag to the primary slot, so probably there was some garbage there already (not previously erased!?).

Question: Is there a way to flash with full erase from command line on linux?

I use: https://github.com/stlink-org/stlink. st-flah erase for mass erase, and st-flash write <bin-file> <address> for write (preceeded by sector erase).

nandojve commented 4 years ago

Thank you guys! Now I need to do some homework.

nandojve commented 4 years ago

Hi @ABOSTM , I open this issue again because I got same problem with zephyr-v2.3.0-1218.

If I do full chip erase and flash zephy_MCUBoot.zip and zephyr-1.0.0_Signed_HelloWorld.zip using cubeprogrammer on Windows, the system works.

This process is valid on Linux using the Utzig suggestion https://github.com/stlink-org/stlink and st-flash erase command followed by west flash zephy_MCUBoot and west flash --hex-file zephyr-1.0.0_Signed_HelloWorld.

Changing MCUBoot for the current version still system working. The system stop to work when I flash any application from main repository. To put system running I need execute again st-flash erase but only your app zephyr-1.0.0_Signed_HelloWorld confirming the boot image.

Note: Once the problem happen even your image don't works without a full erase.

ABOSTM commented 4 years ago

Hi @nandojve , If I understand correctly, it seems there is a regression. Regression is not in MCUBoot but in application. Regression occurs between the time I created zephyr-1.0.0_Signed_HelloWorld.zip and now.

So I suggest to make dichotomy (git bisect) to determine which commit cause the regression.

nvlsianpu commented 4 years ago

@nandojve Is this issue still valid?

nvlsianpu commented 4 years ago

@nandojve testsuite for mcuboot interface functions are here: /tests/subsys/dfu/mcuboot.

nandojve commented 4 years ago

@nandojve Is this issue still valid?

I'll check it again.

nandojve commented 4 years ago

Hi @nvlsianpu , After https://github.com/zephyrproject-rtos/mcuboot/commit/bdcfc859d4b8b4c000a2a46906080e086d048686 I can't even build MCUboot for disco_l475_iot1. The commit message doesn't explain if there are something that should be done on my environment to allow build.

Any tip?

erwango commented 4 years ago

Hi @nvlsianpu , After zephyrproject-rtos/mcuboot@bdcfc85 I can't even build MCUboot for disco_l475_iot1. The commit message doesn't explain if there are something that should be done on my environment to allow build.

Any tip?

@nandojve please raise a dedicated issue for this new problem, it will help tracking.

nvlsianpu commented 4 years ago

@nandojve @erwango We are looking into the build problem anyway.

nvlsianpu commented 4 years ago

^^ Fix https://github.com/zephyrproject-rtos/mcuboot/pull/32 manifest update: https://github.com/zephyrproject-rtos/zephyr/pull/28274

nandojve commented 4 years ago

Hi @nvlsianpu thank you for help us with this. I'll try again later.

erwango commented 4 years ago

@nandojve would you mind rebasing https://github.com/UpdateHub/zephyr/commits/topic/uhu_wifi so we can have a test on recent zephyr version ? Txs

nandojve commented 4 years ago

Hi @erwango , sure! My apologies about delays from my side, it has been very busy these days.

nandojve commented 4 years ago

Hi folks, some updates.

First test: Write files from ABOSTM and confirm board is Ok: Pass

st-flash erase
flash old bootloader
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: none
[00:00:00.013,000] <err> mcuboot: Unable to find bootable image
flash old firmware
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
Hello World! disco_l475_iot1
Confirming the boot image
Image is OK

Second test: Confirm that new MCUboot works as expected only flashing new MCUBoot without erase all flash content. The MCUBoot at a06884a4e6 doesn't run the current v2.3.0-rc1 on the flash: Fail

flash new bootloader
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none
[00:00:00.015,000] <err> mcuboot: Unable to find bootable image

Third test: Confirm that new MCUboot works as expected with full flash erase before upload new MCUBoot and firmware. The MCUBoot at a06884a4e6 works and the current v2.3.0-rc1 run on the flash: Pass

st-flash erase
flash new bootloader
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none
[00:00:00.015,000] <err> mcuboot: Unable to find bootable image
flash old firmware
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
Hello World! disco_l475_iot1
Confirming the boot image
Image is OK

Fourth test: Flash a new firmware with new MCUboot: Fail

flash new firmware
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
Hello World! disco_l475_iot1
Confirming the boot image
Error to confirm the image

Fifth test: Re flash the old firmware with new MCUboot and confirm that works: Fail

flash old firmware
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
Hello World! disco_l475_iot1
Confirming the boot image
Error to confirm the image

Sixth test: Flash old MCUboot and new firmware with full chip erase: Fail

st-flash erase
flash old bootloader
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: none
[00:00:00.013,000] <err> mcuboot: Unable to find bootable image
flash new firmware
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
Hello World! disco_l475_iot1
Confirming the boot image
Error to confirm the image

Seventh test: Revert to old firmware without full chip erase: Fail

*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.013,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
Hello World! disco_l475_iot1
Confirming the boot image
Error to confirm the image

Eighth test: Full erase, new bootloader, old firmware, bad image, old firmware: Ok

st-flash erase
flash new bootloader
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none
[00:00:00.015,000] <err> mcuboot: Unable to find bootable image
flash old firmware
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
Hello World! disco_l475_iot1
Confirming the boot image
Image is OK
flash BAD firmware
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none
[00:00:00.015,000] <err> mcuboot: Image in the primary slot is not valid!
[00:00:00.015,000] <err> mcuboot: Unable to find bootable image
flash old firmware
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
Hello World! disco_l475_iot1
Confirming the boot image
Image is OK

Nineth test: Continuing eighth test: new image, old firmware: Fail

flash new firmware
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
Hello World! disco_l475_iot1
Confirming the boot image
Error to confirm the image
flash old firmware
*** Booting Zephyr OS build v2.4.0-rc1-264-g44ac9d33e69c  ***
[00:00:00.005,000] <inf> mcuboot: Starting bootloader
[00:00:00.006,000] <inf> mcuboot: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.006,000] <inf> mcuboot: Boot source: primary slot
[00:00:00.015,000] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v2.3.0-rc1-122-ge550302a61a0  ***
Hello World! disco_l475_iot1
Confirming the boot image
Error to confirm the image

It seems that Zephyr-2.4.0-rc1 images doesn't confirm and corrupt the whole system. When flash a bad image (eighth test) the system run normally when revert to old firmware.

I confirm that after rebase to 2.4.0-rc1 updatehub doesn't confirm the image and stay rebooting. When I disable image confirmation boot_write_img_confirmed() the system still rebooting. It seems another regression but need more investigation. Because of all this I not able to run UpdateHub using esWiFi on disco_l475_iot1. I'll try run more tests and expects report early next week.

nandojve commented 4 years ago

@nandojve would you mind rebasing https://github.com/UpdateHub/zephyr/commits/topic/uhu_wifi so we can have a test on recent zephyr version ? Txs

Rebased on top of 2.4.0-rc2. The 28b9617f5ee1123413ef92d1a74469402272ba81 is full functional here at ETH/WIFI/MODEM. Don't forget to change configs:

at prj.conf
CONFIG_UPDATEHUB_SERVER="<IP>"

IP: can be on local network or internet. DNS names will be resolved.
This way a docker machine can run updatehub-ce at any place.

at overlay-wifi.conf
CONFIG_UPDATEHUB_WIFI_SSID="<SSID>"
CONFIG_UPDATEHUB_WIFI_PSK="<PASSWD>"
nvlsianpu commented 4 years ago

Can you describe clear operation sequence required to reproduce the file: eg:

  1. flash mcuboot of version xxx and application
  2. upload image of , set it to test...
  3. ...

I have only nRF52xxdks boards so want to reproduce yours results using smp_svr sample. So fare I can't.

nandojve commented 4 years ago

Hi @nvlsianpu , the project that I try run is https://github.com/UpdateHub/zephyr/commit/74ae362d7b806c2957c57c2203b189141a33a9a1

I sign the image and upload with west flash --hex.... All that I reported on the old post is related to the image at slot-0 after flash, and the above commit is the new firmware. I think you don't need use smp_svr because problem shows with west flash.

old MCUboot(bootloader) zephy_MCUBoot.zip

old firmware zephyr-1.0.0_Signed_HelloWorld.zip

Originally posted by @ABOSTM in https://github.com/zephyrproject-rtos/zephyr/issues/25010#issuecomment-630280091

Sequence is inside old post, try resume the first test, eighth and nine: st-flash erase flash old bootloader flash old firmware result: OK

Eighth test: Full erase, new bootloader, old firmware, bad image, old firmware: Ok st-flash erase flash new bootloader flash old firmware flash BAD firmware (image without sign) flash old firmware result: OK

Nineth test: Continuing eighth test: new image, old firmware: Fail flash new firmware flash old firmware

So, when I flash the new firmware at slot-0 using west it fail to confirm the image and somehow compromise the whole system. I mean, a old firmware (that always works) only confirm after full chip erase. I believe it can be something related only to ST SoCs.

I start to think this is the key related to the problem that I've been facing with ST SoC that MCUboot don't swap slot-1 to slot-0 keeping updatehub on a infinite upgrade loop.

nvlsianpu commented 4 years ago

@nandojve What you men by new bootloader, old bootloader, new firmware and old firmware?

nandojve commented 4 years ago

@nvlsianpu it is about versions old: v2.3.0-rc1-122 new: v2.4.0-rc1-264

github-actions[bot] commented 3 years ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.