makefiles: add FAST_FLASH option to speed up flashing

[benpicco]

Contribution description

When iterating on a firmware long programming times can be quite distracting. Major slowdown come from

• flashing slot0-extended.bin which will overwrite the entire first slot + first few bytes of the 2nd slot. The idea is to clear out the 2nd slot header, so we don't boot that by accident if the version number is higher. But if we flash the firmware onto the same device during development, there is no reason to do this.
• We read back the firmware from the device twice: Once before flashing to check if we need to flash at all and a 2nd time after flashing to ensure all bytes have been written correctly. But we can just skip that - I've never seen the verify step fail.

We don't want to skip those steps during production though, so keep the default behavior.
But during development, setting FAST_FLASH=1 will yield a nice speedup.

Testing procedure

Try it out with make flash FAST_FLASH=1

Issues/PRs references

[kfessel]

I don't think we gain much by not verifying as its only verifying what it wrote (about a 1/10 of the time),
The gain of not flashing halve the memory is huge, but not verifying might lead to long sessions of "why dosn't this work?"

wrote 540672 bytes ... slot0-extended.bin in 11.620594s (45.437 KiB/s)

verified 533504 bytes in 1.287412s (404.688 KiB/s)

wrote 172032 bytes from ...slot0-combined.bin in 3.886535s (43.226 KiB/s)

verified 171208 bytes in 0.423514s (394.781 KiB/s)

[mguetschow]

• flashing slot0-extended.bin which will overwrite the entire first slot + first few bytes of the 2nd slot.

That only applies when riotboot is used right? Could we instead have a flag / configuration option that clearly belongs to riotboot, i.e., by prefixing it with RIOTBOOT?

Also I agree with @kfessel that I would rather not disable verify unless it brings considerable speedup. At least I would split the two parts into separate flags (and PRs).

[maribu]

OpenOCD normally does the verification by uploading a trivial executable to RAM and making the MCU execute this. This executable computes the checksum, which OpenOCD then fetches. This is super-duper fast.

Only when this fails (e.g. because no checksum calculating firmware is available or the checksums did not match) it will read back what was written and provide details on which bytes did not match.

On working MCUs I also have never seen a failed verification. But the verification step is quite good in detecting broken MCUs.