-
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
riotboot/flashwrite: use flashpage_raw when available #11683
Conversation
- If supported when finishing flashwrite, i.e. writing RIOT magic number, if FLASHPAGE_RAW is supported it will be used insetad of FLASHPAGE to avoid copying and erasing the page. - This also allows it work for sectors based flash, e.g. stm32f4
aabdf42
to
b2a7e74
Compare
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 looks fine. Will try to test tomorrow.
(Some of the alignment changes were a little off, fixing from too little spaces to too many.)
@@ -0,0 +1,151 @@ | |||
/* |
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.
hmmmm ;)
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.
Hm, shouldn't flashpage_raw allow to not allocate a whole flash page as buffer?
The idea would be to erase a page on first write, but then write in FLASHPAGE_RAW_BLOCKSIZE sized chunks.
Closed in favor of #11705 |
Contribution description
The following PR allows using
flashpage_write_raw()
to finish an update process. The main objective of this is to support OTA onstm32f4/2/7
. Since the flash is sector based if at the finish we are to perform an erase operation the whole sector would be erased (sectors that go from 16KB to 256KB). The idea is that since we only need to write 4 bytes ifflashpage_write_raw()
is available erasing the sector again can be avoided since it was already erased at the start of theflashwrite
process. So as long as the first 4 bytes are kept in an erased state '0xFF'flashpage_write_raw()
can be used.Testing procedure
for nucleo-l073rz:
make -C tests/riotboot_flashwrite/ BOARD= nucleo-l073rz riotboot/flash term
make -C tests/riotboot_flashwrite/ BOARD= nucleo-l073rzriotboot
coap-client -m post coap://[fe80::2%tap0]/flashwrite -f tests/riotboot_flashwrite/bin/ nucleo-l073rz/tests_riotboot_flashwrite-slot1.riot.bin -b 64
for samr21-xpro:
make -C tests/riotboot_flashwrite/ BOARD= samr21-xpro riotboot/flash term
make -C tests/riotboot_flashwrite/ BOARD= samr21-xpro rzriotboot
coap-client -m post coap://[fe80::2%tap0]/flashwrite -f tests/riotboot_flashwrite/bin/ samr21-xpro/tests_riotboot_flashwrite-slot1.riot.bin -b 64
When the update finished reboot the node manually it should have started from a different slot.
nucleo-f446re
make -C tests/riotboot_flashwrite/ BOARD=nucleo-f446re riotboot/flash term
make -C tests/riotboot_flashwrite/ BOARD=nucleo-f446re riotboot
coap-client -m post coap://[fe80::2%tap0]/flashwrite -f tests/riotboot_flashwrite/bin/ nucleo-f446retests_riotboot_flashwrite-slot1.riot.bin -b 64
Issues/PRs references
Related to #11682 and #1168