Implement fast write + ring buffer

[aq1018]

This PR implement user flash fast write + ring buffer in place of standard writes.

Why

We need to use fast write for user flash for two reasons:

1. Not all chips support standard halfword writes. CH32V00X and CH32X033/035 and possibly later chips do not support halfword standard writes. In order to streamline tinyboot protocol, we need to standardize the write against standard writes.
2. Transport payload and flash page size decoupling. Certain CH32 chips support USB FS or even Bluetooth based transports in addition to UART. This means protocol payload size is transport dependent. Different chips also has different flash page sizes. For example, V003 has 64 bytes page size, and V00X/X033/X005 has 128 bytes page size, while more powerful chips has 256 bytes chip size. In order to implement fast writes efficiently, a buffer is needed to decouple the two.

Behavior

• A PAGE_SIZE *2 (128 bytes for V003) ring buffer is used to buffer protocol payload. This allows a full flash page to fit in the buffer while still have room for at least one protocol payload being buffered. Thus, protocol payload must not be larger than a single flash page size.
• During WRITE command operation, the bootloader will buffer the payload, check if the buffer has enough data for a full page write, and automatically flush the whole page if buffer contains at least a full page size.
• A FLUSH command is added so that the CLI can manually flush the buffer. There are two use cases:
  • Last chunk - The CLI needs to send flush command after the last write command to ensure the remaining data in buffer is written to flash.
  • Non-continuous writes - If the CLI needs to write in a discontinuous fashion, a flush command MUST be issued before jumping to the next non-continuous address.

The bootloader remains mostly stateless and simple so it can fit in 1920 bytes of system flash storage.

Note

This implementation overflows the system flash (1920 bytes) by about 142 bytes. So the system flash CI build will fail and is expected. Another PR will be filed to optimize flash size. The purpose of this PR is get the fast write implementation behave correctly.

[aq1018]

Merged. Everything passes, other than the system-flash example overflowing, which is expected.