Fix readme #12
Fix readme #12
Conversation
| @@ -181,8 +187,6 @@ Explanation of each option: | |||
| - `--header-size 4096`: this must be the same as the value specified in `mcuboot.header-size` configuration (4096 bytes by default) | |||
| - `--pad-header`: this tells imgtool to insert the entire header, including any necessary padding bytes. | |||
| - `-S 0xC0000`: this specifies the maximum size of the application ("slot size"). It **must** be the same as the configured `mcuboot.slot-size`! | |||
| - `--pad`: this should only be used for binaries you plan on initially flashing to your target at the factory. It pads the resulting binary to the slot size and adds initialized trailer TLVs. This is not needed for update binaries. | |||
There was a problem hiding this comment.
@boraozgen Have you tested this? It was my impression that the trailer TLVs are not appended by imgtool to the signed binary unless the --pad flag is included. I will have to test booting an application that has been signed without the --pad flag...
There was a problem hiding this comment.
I do not use --pad at all, it works fine.
There was a problem hiding this comment.
In my experience --pad pads the image to fit the slot and adds the trailers just before the end of the slot. I don't know what would be a use case for this.
There was a problem hiding this comment.
The --pad option causes problems on DISCO_L475VG_IOT01A. I still don't fully understand how it works, but if we want to put the board in a clean state, it's way more reliable to erase the chip
pyocd erase --chip
Then run the demo from beginning to end, without --pad.
There was a problem hiding this comment.
The latest MCUboot documentation explains it:
The optional --pad argument will place a trailer on the image that indicates that the image should be considered an upgrade. Writing this image in the secondary slot will then cause the bootloader to upgrade to it.
So it's intended for the secondary slot only, and
- without
--pad, the current application needs to callboot_set_pending()to active the secondary image and let MCUboot apply it. - with
--pad, the secondary image already comes pre-activated, so MCUboot will apply it. - will
--pad --confirm, the secondary image comes pre-activated and pre-confirmed, so MCUboot will apply it and there will be no need toboot_set_confirmed()afterwards.
It's no replacement for erasing the primary slot into a clean state by ourselves (or the manufacturing process).
There was a problem hiding this comment.
So before flashing the initial primary image at the factory, it's the manufacturer's responsibility to put the chip in a clean state by erasing it. Using pyocd erase --chip is what we can do with Mbed boards. It makes sense that MCUboot doesn't provide a utility to clean up the primary slot, because it should be a prerequisite before we even place MCUboot onto the board.
There was a problem hiding this comment.
@pan- FYI, removing this --pad should resolve the problem you encountered.
Fixes #10