-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cpu/stm32f4: add riotboot requirements #11682
Conversation
It seems there is a confusion between slots and sectors in this sentence. From my understanding, it should be: Since F4 works with sectors, for riotboot to work, each slot must start at the beginning of a sector. For stm32f4 the smallest sector is of length 16kB... This PR also needs a rebase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have comments on comments.
cc16e33
to
275d566
Compare
@aabadie comments addressed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code changes are good and well explained. I tested on nucleo-f446re and on nucleo-f410rb (even if the feature is not added on this one) and it worked on both.
ACK
Please squash and trigger Murdock after. |
b702243
to
cf6fb12
Compare
- Stm32f4 use sectors instead of pages. They go from 16 KB to 128KB. The bootloader will use the first sector(16Kb). Slots must start at the begining of a sector to not overlap. - Minimum required RIOBOOT_HDR_LEN or stm32f4 is 0x200 to respect vector table alignment
cf6fb12
to
bfcb963
Compare
@aabadie I squashed and modified the commit message, there where some typos. I also removed:
Which was already defined for riotboot. |
Ok, I'll have a second look tomorrow, if I find time, just in case. |
I tested a second time this PR and it works. Let's go! |
@aabadie Thanks for the review! |
Contribution description
This PR adds riotboot for stm32f4. Since F4 works with sectors for riotboot to work each slot must start at the beginning of a
slotsector. For stm32f4 the smallestslotsector is of length 16kB, therefore that must be the length of the bootloader and the same amount must be taken from the second half of the flash to optimize flash usage.This PR is part of 3, since just adding riotboot doesn't make much sense if it can't perform ota. Although it doesn't depend on them it is highly related to:
Testing procedure
It has been tested on the supported boards:
nucleo-f446re
andstm32f429i-disc1
.1.- Test riotboot:
BOARD=nucleo-f446r FEATURES_REQUIRED+=riotboot make -C tests/xtimer_usleep riotboot/flash-extended-slot0 term
BOARD=nucleo-f446rFEATURES_REQUIRED+=riotboot make -C tests/xtimer_usleep riotboot/flash-slot1 term
In both cases it should run without issues.
2.- Since the sector division is important when updating the slots by writing to flash directly it would be ideal to reba se on top off flashpage: #11681 and #11683
and run
tests/riotboot_flashwrite
The following patch can be applied to the test Makefile
Then to test:
make -C tests/riotboot_flashwrite/ BOARD=stm32f429i-disc1 riotboot/flash term
make -C tests/riotboot_flashwrite/ BOARD=stm32f429i-disc1 riotboot
coap-client -m post coap://[fe80::2%tap0]/flashwrite -f tests/riotboot_flashwrite/bin/stm32f429i-disc1/tests_riotboot_flashwrite-slot1.riot.bin -b 64
When the update finished reboot the node manually it should have started from a different slot.
Issues/PRs references
Related to #11681 and #11683