Closed danieldegrasse closed 6 hours ago
@danieldegrasse with this PR RT series are ok, but all lpc series failed.
lpcxpresso55s06
mimxrt685_evk/mimxrt685s/cm33
lpcxpresso55s28
mimxrt1170_evk/mimxrt1176/cm7
lpcxpresso55s36
lpcxpresso55s69/lpc55s69/cpu0
and mimxrt1040_evk still fails at my side with below log
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot
*** Booting Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
Launching primary slot application on mimxrt1040_evk
Secondary application ready for swap, rebooting*** Booting MCUboot v2.1.0-rc1 ***
*** Using Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x3, copy_done=0x3, image_ok=0x1
I: Boot source: none
I: Image index: 0, Swap type: perm
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot
*** Booting Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
Launching primary slot application on mimxrt1040_evk
Secondary application ready for swap, rebooting*** Booting MCUboot v2.1.0-rc1 ***
*** Using Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x3, copy_done=0x3, image_ok=0x1
I: Boot source: none
I: Image index: 0, Swap type: perm
lpcxpresso55s06
mimxrt685_evk/mimxrt685s/cm33
lpcxpresso55s28
mimxrt1170_evk/mimxrt1176/cm7
lpcxpresso55s36
lpcxpresso55s69/lpc55s69/cpu0
and mimxrt1040_evk still fails at my side with below log
How are you testing for these platforms? On my tests the RT1040 EVK worked fine with this change. Also, the LPC series parts (and the RT685) will not use this flash driver, so I believe those failures are unrelated
How are you testing for these platforms? On my tests the RT1040 EVK worked fine with this change. Also, the LPC series parts (and the RT685) will not use this flash driver, so I believe those failures are unrelated
let me check mimxrt1040_evk and mimxrt1020_evk again.
same problem still, @danieldegrasse
Platfrom| mainline result| your PR result -- | -- | -- mimxrt1040_evk| PASS (after ease board before testing) | Fail(after erase board before testing) mimxrt1020_evk| Fail no console output at all | fail no console output at alland this PR did fix the issue in mimxrt1015, and other RT10xx series. LPC series issue seems it does not support swap, I am checking with Andrej.
On the RT1040: Commands used:
$ west build -p always -b mimxrt1040_evk tests/boot/test_mcuboot/ --sysbuild
$ JLinkExe
> connect
> exec EnableEraseAllFlashBanks
> erase 0x60000000 0x60100000
> exit
$ west flash
Console output:
*** Booting MCUboot v2.1.0-rc1-1-gd4394c2f9b76 ***
*** Using Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
W: Failed reading image headers; Image=0
E: Unable to find bootable image
*** Booting MCUboot v2.1.0-rc1-1-gd4394c2f9b76 ***
*** Using Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
W: Failed reading image headers; Image=0
E: Unable to find bootable image
*** Booting MCUboot v2.1.0-rc1-1-gd4394c2f9b76 ***
*** Using Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot
*** Booting Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
Launching primary slot application on mimxrt1040_evk
Secondary application ready for swap, rebooting*** Booting MCUboot v2.1.0-rc1-1-gd4394c2f9b76 ***
*** Using Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=good, swap_type=0x3, copy_done=0x3, image_ok=0x1
I: Boot source: none
I: Image index: 0, Swap type: perm
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot
*** Booting Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
Swapped application booted on mimxrt1040_evk
RT1020
Building and flashing hello_world
does not work for me on main
(8ae0934470c9cd2bc56). Can you check this on your end? While there is likely an issue here, I'm not sure if it is caused by this PR
On the RT1040: Commands used:
$ west build -p always -b mimxrt1040_evk tests/boot/test_mcuboot/ --sysbuild $ JLinkExe > connect > exec EnableEraseAllFlashBanks > erase 0x60000000 0x60100000 > exit $ west flash
Console output:
*** Booting MCUboot v2.1.0-rc1-1-gd4394c2f9b76 *** *** Using Zephyr OS build v3.6.0-3286-g518be4d0a763 *** I: Starting bootloader I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1 I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 I: Boot source: none W: Failed reading image headers; Image=0 E: Unable to find bootable image *** Booting MCUboot v2.1.0-rc1-1-gd4394c2f9b76 *** *** Using Zephyr OS build v3.6.0-3286-g518be4d0a763 *** I: Starting bootloader I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1 I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 I: Boot source: none W: Failed reading image headers; Image=0 E: Unable to find bootable image *** Booting MCUboot v2.1.0-rc1-1-gd4394c2f9b76 *** *** Using Zephyr OS build v3.6.0-3286-g518be4d0a763 *** I: Starting bootloader I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1 I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 I: Boot source: none I: Image index: 0, Swap type: none I: Bootloader chainload address offset: 0x10000 I: Jumping to the first image slot *** Booting Zephyr OS build v3.6.0-3286-g518be4d0a763 *** Launching primary slot application on mimxrt1040_evk Secondary application ready for swap, rebooting*** Booting MCUboot v2.1.0-rc1-1-gd4394c2f9b76 *** *** Using Zephyr OS build v3.6.0-3286-g518be4d0a763 *** I: Starting bootloader I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1 I: Secondary image: magic=good, swap_type=0x3, copy_done=0x3, image_ok=0x1 I: Boot source: none I: Image index: 0, Swap type: perm I: Starting swap using move algorithm. I: Bootloader chainload address offset: 0x10000 I: Jumping to the first image slot *** Booting Zephyr OS build v3.6.0-3286-g518be4d0a763 *** Swapped application booted on mimxrt1040_evk
I use linkserver, and erase it by
LinkServer flash -p "DSAWCQJR" MIMXRT1042xxxxB:MIMXRT1040-EVK erase
which works for mainline code, but not in this PR
RT1020
Building and flashing
hello_world
does not work for me onmain
(8ae0934). Can you check this on your end? While there is likely an issue here, I'm not sure if it is caused by this PR
I am using linkserver which works fine for me, and I remember there is a jlink issue with flash timing that you found. Our sdk change the flash timing, which will crash the jlink process. and hello_world is working at your PR at my side as well
log for mainline
*** Booting Zephyr OS build v3.6.0-3654-ge6281c9d21dd ***
Hello World! mimxrt1020_evk/mimxrt1021
log for your PR
*** Booting Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
Hello World! mimxrt1020_evk/mimxrt1021
BTW:
*** Booting MCUboot v2.1.0-rc1-1-gd4394c2f9b76 ***
*** Using Zephyr OS build v3.6.0-3286-g518be4d0a763 ***
I: Starting bootloader
I: Primary image: **magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1**
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
**W: Failed reading image headers; Image=0**
**E: Unable to find bootable image**
The MCUBoot log is misleading. It declares that primary image image_ok and magic are good, but failed reading image header and not able to find bootable image. So magic, swap_type, copy_done, image_ok values can be ignored for the primary image. If to do a flash mass erase before they will have initial values: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3, only after a successful swap they will be updated to magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1
which works for mainline code, but not in this PR
The branch this PR was based on did not have .hex
support for Linkserver added yet in the runner. I've rebased the branch, and things work fine for me now- can you try to test on the RT1040 again?
The branch this PR was based on did not have
.hex
support for Linkserver added yet in the runner. I've rebased the branch, and things work fine for me now- can you try to test on the RT1040 again?
in RT1040 we do not configure the CONFIG_BUILD_OUTPUT_HEX, does this matter?
with the latest code i still get problem with ubuntu@ubuntu-OptiPlex-5090:~/nxp/mimxrt1040_evk/zephyr$ cat /home/ubuntu/nxp/mimxrt1040_evk/zephyr/twister-out/mimxrt1040_evk/tests/boot/test_mcuboot/bootloader.mcuboot/handler.log Booting MCUboot v2.1.0-rc1-1-gd4394c2f9b76 Using Zephyr OS build v3.6.0-3822-g91fb30c7a794 I: Starting bootloader I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 I: Boot source: none W: Failed reading image headers; Image=0 E: Unable to find bootable image
in RT1040 we do not configure the CONFIG_BUILD_OUTPUT_HEX, does this matter?
It is enabled in the tests\boot\test_mcuboot\swapped_app\prj.conf
It is enabled in the tests\boot\test_mcuboot\swapped_app\prj.conf
May I know you build and flash command line? It still fails at my side.
May I know you build and flash command line? It still fails at my side.
# Erase flash first, just to be sure
$ LinkServer flash --probe "ERA3BQGQ" MIMXRT1042xxxxB:MIMXRT1040-EVK erase
$ west build -p always -b mimxrt1040_evk tests/boot/test_mcuboot/ --sysbuild
$ west flash -r linkserver --probe ERA3BQGQ
I find this is my on board flash issue, though more deep analysis needed, but this PR is good.
Implement more robust handling for legacy SFDP tables, which may not implement some of the JEDEC defined DWORDS for SFDP data. Instead of failing to probe/initialize the flash when these DWORDS are not defined in the basic flash parameter table, revert to sane defaults for SPI flash.
Fixes #72051
This change was verified on the the following EVKs: