Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Requirements for writing to slot-1? #488

Closed
endian-benjamin opened this issue May 29, 2019 · 6 comments
Closed

Requirements for writing to slot-1? #488

endian-benjamin opened this issue May 29, 2019 · 6 comments

Comments

@endian-benjamin
Copy link

I'm trying to get mcuboot to work outside the context of ready-made samples, because we need to implement our own transport method for delivering FOTA images to slot-1. Tried inspecting the code for mcumgr to see if there's anything special that needs to be done in order to flash a signed image to slot-1 and have mcuboot verify and swap to it at next boot.

From what I could tell, signing and writing the new image to SLOT_1_OFFSET should be sufficient for mcuboot to autodetect it? That doesn't work for me for some reason. Do I have to write something to scratch as well?

Running Zephyr v1.14, mcuboot master on an nRF52840, slot offsets: 0xC000/0x73000, slot size 0x67000. I'm using openocd to flash all slots:

    ../src/./openocd -s $PWD -f interface/stlink.cfg \
        -c "transport select hla_swd" \
        -c "set WORKAREASIZE 0" \
        -f target/nrf52.cfg -c init -c halt \
        -c "program $SIGNED_IMG verify 0x73000"

mcuboot works fine, slot-0 works fine, but mcuboot never detects that anything is present in the secondary slot it seems. Console output from mcuboot:

[00:00:00.084,564] <inf> mcuboot: Starting bootloader
[00:00:00.170,776] <inf> mcuboot: Primary image: magic=unset, copy_done=0x3, image_ok=0x3
[00:00:00.318,878] <inf> mcuboot: Scratch: magic=unset, copy_done=0x30, image_ok=0x3
[00:00:00.446,655] <inf> mcuboot: Boot source: primary slot
[00:00:00.555,114] <inf> mcuboot: Swap type: none
[00:00:00.961,334] <inf> mcuboot: Bootloader chainload address offset: 0xc000
[00:00:00.998,931] <inf> mcuboot: Jumping to the first image slot

Any ideas? Is it weird that it only reports status for scratch and nothing for "Secondary image"?

@utzig
Copy link
Member

utzig commented May 29, 2019

You should never touch scratch yourself. What was your imgtool command line? Did you pad your image? (without padding, the bootloader will just ignore it because it is not "set" for upgrade).

@endian-benjamin
Copy link
Author

imgtool worked fine, as I said I flashed and booted slot-0 without problems. But:

 ~/zephyrproject/mcuboot/scripts/./imgtool.py sign           \
          --key mcuboot/root-rsa-2048.pem                                 \
          --header-size 0x200                                \
          --align 8                                          \
          --version 1.2                                      \
          --slot-size 0x67000                             \
          $ZEPHYR_BIN_DIR/zephyr.bin                    \
          $ZEPHYR_BIN_DIR/signed.bin

I did not add padding, so that's probably the issue - what format should the padding be?

@utzig
Copy link
Member

utzig commented May 29, 2019

You only need to pad the image that goes into slot-1.

@utzig
Copy link
Member

utzig commented May 29, 2019

Btw, those messages look totally fine, it does not show any info about slot-1's image if it is not set for an upgrade operation.

@endian-benjamin
Copy link
Author

But it SHOULD be set for an upgrade after I flash an image to slot-1.

"Padding" means appending zeros to the binary so that it is of size SLOT_SIZE, yes?

@endian-benjamin
Copy link
Author

Oh now I noticed, you just add --pad to imgtool.py as an argument...

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants