riotboot/flashwrite: use chunks instead of pages, support flashpage_write_raw

[fjmolinas]

Contribution description

The following PR changes the approach used for flashwrite. Instead of always writing pages it writes chunks into flash. If flashpage_raw is supported these chunk can be smalled than FLASHPAGE_SIZE allowing for buffers as small as FLASHPAGE_RAW_BLOCKSIZE. This will also allow supporting stm32f4/2/7` or sectors based CPU since we can pick when to erase the flash.

The PR involves three changes (I can open separate PR's if the spirit of the PR is agreed upon):

• Introduces a FLASH_ERASE_STATE variable so the when skipping an offset or in this case RIOTBOOT_MAGIC we keep those bytes in an erase state so they don't need to be overwritten.
• Introduces flashpage_write_and_verify_raw and flashpage_write_raw. These are convenience functions.
• Changes the behaviour of flashwrite to be based on chunks

When implementing #11683 I was too focused on making it work for stm32f2/4 and not on the global picture I think this approach works better by still having the same behavior for the base case an completely removing the use of page buffers when possible.

A buffer is still kept in riotboot_flashwrite_t for convenience, it makes it easier and more robust to handle unaligned riotboot_flashwrite_putbytes. The buffer could always be defined to FLASHPAGE_RAW_BLOCKSIZE. The choice of 64 bytes I made is based on having it the same size as a coap_block. But it could be changed

Testing procedure

1. Verify that everything still works on supported board that support and don't support flashpage. Applying this diff can help in testing over ethos:

diff --git a/tests/riotboot_flashwrite/Makefile b/tests/riotboot_flashwrite/Makefile
index 32f127d70..d3c9f20b4 100644
--- a/tests/riotboot_flashwrite/Makefile
+++ b/tests/riotboot_flashwrite/Makefile
@@ -39,11 +39,17 @@ LOW_MEMORY_BOARDS := nucleo-f334r8
 GNRC_NETIF_NUMOF := 2
 
 # uncomment these to use ethos
-#USEMODULE += ethos gnrc_uhcpc
+USEMODULE += ethos gnrc_uhcpc  stdio_uart_rx
 #
 ## ethos baudrate can be configured from make command
-#ETHOS_BAUDRATE ?= 115200
-#CFLAGS += -DETHOS_BAUDRATE=$(ETHOS_BAUDRATE) -DUSE_ETHOS_FOR_STDIO
+ETHOS_BAUDRATE ?= 115200
+CFLAGS += -DETHOS_BAUDRATE=$(ETHOS_BAUDRATE) -DUSE_ETHOS_FOR_STDIO
+
+TAP ?= tap0
+IPV6_PREFIX ?= 2001:db8::/64
+
+TERMPROG ?= sudo sh $(RIOTTOOLS)/ethos/start_network.sh
+TERMFLAGS ?= $(PORT) $(TAP) $(IPV6_PREFIX)
 
 ifneq (,$(filter $(BOARD),$(LOW_MEMORY_BOARDS)))
   $(info Using low-memory configuration for microcoap_server.)

for nucleo-l073rz:

• provided the node make -C tests/riotboot_flashwrite/ BOARD= nucleo-l073rz riotboot/flash term
• compile new firmware: make -C tests/riotboot_flashwrite/ BOARD= nucleo-l073rzriotboot
• launch an updated: 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:

• provided the node make -C tests/riotboot_flashwrite/ BOARD= samr21-xpro riotboot/flash term
• compile new firmware: make -C tests/riotboot_flashwrite/ BOARD= samr21-xpro rzriotboot
• launch an updated: 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.

2. rebase on top of cpu/stm32f4: add riotboot requirements #11682 and cpu/stm32f7/4/2: add flashpage and flashpage_raw #11681 and test over an stm32f4 board, e.g. nucleo-f446re

• provided the node make -C tests/riotboot_flashwrite/ BOARD=nucleo-f446re riotboot/flash term
• compile new firmware: make -C tests/riotboot_flashwrite/ BOARD=nucleo-f446re riotboot
• launch an updated: 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

Replaces #11683

Related to #11682 and #1168

[fjmolinas]

@kaspar030 After your comments in #11683 I realized I had been too focused on the problem in front of me to see the whole picture. I opened this PR as a more global approach to what was done in #11683. There are more changes involved and the objective is not exactly the same so I rather open a separate PR, as its a different approach.

PS: Sorry for taking so long to address your comments, I was a little bit busy and distracted last week :)

[fjmolinas]

@kaspar030 As discussed offline, what would you think of this approach (assuming chunk are replaced by blocks)?

[fjmolinas]

@kaspar030 testing is much easier with #11808 :).

[fjmolinas]

BTW, changes chunks base size to BLOCKSIZE

[benpicco]

Why WIP?

[miri64]

Why WIP?

@fjmolinas please provide an explanation ;-).

[fjmolinas]

@fjmolinas please provide an explanation ;-).

I had answered offline, but good to put it here. This PR has diverged enough from master that it is no longer working, I'll close unless I get it working again.