riotboot: implement serial flasher

[benpicco]

Contribution description

I got annoyed by boards that require wiring up a programmer and that are finicky to flash.
Therefore I added a simple protocol to riotboot that allows to erase sectors / write data over a serial connection.

There are only four commands:

• erase sector
• get sector of address
• write data to address
• boot

This comes with a custom flash tool (riotboot_serial) that is used to transfer the firmware onto a board using riotboot.
So far, this is only wired up for the sam0 family (and comes with a patch that fixes a hard fault on samd5x when writing small chunks).

edit also added efm32 and nrf52, successfully flashed boards using riotboot serial with those platforms.

The flash tool is rather simple and does not do proper error handling yet (it expects the user to just interrupt it if it gets stuck).
The lines from the .hex file are converted to binary

I considered sending raw lines from the .hex file directly, but decided against so the bootloader doesn't have to parse text.
Also sending binary over the wire should be faster.

If the sync protocol makes sense / the 'double sync' is necessary is up for debate, also batching multiple lines of the hex file would probably be faster.

There is also no support for doing anything with riotboot headers yet.
If they are part of the hex file and can be handled transparently, it should just work, but I did not test this.

Testing procedure

For the riotboot bootloader, enable the riotboot_serial and disable riotboot_slot.
It is possible to have both modules active at the same time, but then riotboot will also check if the slot has a valid header, which makes testing/firmware generation more complicated.

With this configuration, 'raw' images (plain RIOT firmware) will boot.

--- a/bootloaders/riotboot/Makefile
+++ b/bootloaders/riotboot/Makefile
@@ -21,10 +21,10 @@ DISABLE_MODULE += auto_init auto_init_%
 USEMODULE += stdio_null
 
 # Include riotboot flash partition functionality
-USEMODULE += riotboot_slot
+# USEMODULE += riotboot_slot
 
 # Include serial bootloader functionality
-# USEMODULE += riotboot_serial
+USEMODULE += riotboot_serial

Now you should be able to flash any RIOT application using PROGRAMMER=riotboot_serial. Start the flashing procedure, then reset the board for the flasher to sync up with the bootloader.
You can also enable the riotboot_reset module which gives you the bootloader command to reboot to the bootloader from the shell.

Issues/PRs references

[aabadie]

For the CI, I would also add:

• a step for dist/tools/riotboot_serial in the tools-buildtest action
• a test application like test/riotboot_serial

Otherwise the code in this PR is not built on Murdock.

[dylad]

How about creating a new application under bootloader/ instead ?
something like bootloader/riotboot_serial ?
Otherwise bootloader/riotboot will become a mess with serial flasher and DFU addition...

[fjmolinas]

For the CI, I would also add:

* a step for ` dist/tools/riotboot_serial` in the tools-buildtest action

* a test application like `test/riotboot_serial`

Otherwise the code in this PR is not built on Murdock.

These change requests seem to still be pending. I'll give this a test

[fjmolinas]

Why a hex file?

[benpicco]

Because it contains the target addresses and is easy to parse

[fjmolinas]

I think it should check that the firmware to be flashed is a hex then (should still be overridable in case a user specifies a firmware path)

[fjmolinas]

@benpicco do you think it's possible to add a README.md for the new bootloader? Something simple on how the BOARD needs to be bootstrapped and flashed?

[fjmolinas]

I think it's better to remove riotboot_slot, right now the bootloader can't possible support riotboot_slot since it can only flash hexfiles and all riotboot functionality relies on flashing bin.

Sure it could initially be bootstrapped with a riotboot_serial + riotboot_slot firmware but no firmware upgrades over serial can be made.

[benpicco]

Ok, although that's not a limitation of the bootloader but the flasher tool

[fjmolinas]

Yes, but will it make sense to use the bootloader in that case?

[fjmolinas]

Please squash!

[fjmolinas]

Ah wai

Please squash!

Ah wait this is still missing:

For the CI, I would also add:

a step for dist/tools/riotboot_serial in the tools-buildtest action
a test application like test/riotboot_serial

Otherwise the code in this PR is not built on Murdock.

[fjmolinas]

@benpicco can you add:

diff --git a/.github/workflows/tools-buildtest.yml b/.github/workflows/tools-buildtest.yml
index fee41ab581..7cd5e28d21 100644
--- a/.github/workflows/tools-buildtest.yml
+++ b/.github/workflows/tools-buildtest.yml
@@ -71,3 +71,7 @@ jobs:
       uses: aabadie/riot-action@v1
       with:
         cmd: make -C dist/tools/lpc2k_pgm
+    - name: Build riotboot_serial tool
+      uses: aabadie/riot-action@v1
+      with:
+        cmd: make -C dist/tools/riotboot_serial

You can squash afterwards.

[fjmolinas]

ACK, I think there is still some improvements to be had (in the future) like being able to flash binaries, but the current state works already and is usable for many applications BOARD's where an external programmer is currently needed.

[benpicco]

Thank you for the review!