lotus,azalea: officially reserve the top 4k of flash for SPI_FLAGS

[DHowett]

Right now, the configuration storage support in lotus/src/flash_storage.c claims overship of the top 0x1000 bytes of flash and stores non-volatile configuration data in it.

However, the last 0x20 bytes of flash contain the RW_FWID (RW version) section. In addition, RW_FW is specified as covering the entire top 0x40000 bytes of flash.

In short, flash looks roughly like this (not to scale)

+----------------------------------+-40000------------~----------------+
| RO_FW                            | RW_FW                             |
|                          RO_FRID |                           RW_FWID |
+----------------------------------+------------------~--------^-7FFE0-+

flash_storage can, if it grows large enough, corrupt the RW version ID. If the RW firmware also grows large enough, flash_storage can overwrite part of it (!).

+----------------------------------+-40000------------~--+-7F000-------+
| RO_FW                            | RW_FW               |spi flag spi |
|                          RO_FRID |                     |flag Rp_ WlD |
+----------------------------------+------------------~--+-~---^-7FFE0-+

This change moves RW_FWID down to 0x7EFE0 and indicates in the FMAP that the RW section can only occupy the top 0x3F000 bytes of flash.

The final layout looks more like this:

+----------------------------------+-40000----~----------+-7F000-------+
| RO_FW                            | RW_FW               |spi flag spi |
|                          RO_FRID |             RW_FWID |flag spi fla |
+----------------------------------+----------~--^-7EFE0-+-------------+

If the RW section grows too large for SPI flags, it will result in a hard build break. That's probably much better than runtime corruption of its .text. :)

[DHowett]

This has been built, tested and deployed to hardware. The device in question still works. 😁