Open mikee47 opened 3 years ago
Continuing from above, here are the require steps to perform an OTA upgrade:
APP 2
partitionAPP 1
APP
. If this fails, the next reboot would revert to APP 2
which, being Sming 4.2, is ignorant of partition tables so will work as before.APP 1
as default boot application. The next OTA update would then flash a Sming 4.3 image to APP1, etc.If anyone has attempted this, please post and we'll see if there are framework changes that can be made to simplify/ease the process. At the very least, we should ensure the documentation covers this process.
I would suggest the following layout:
Such a setup will make it possible to do remote upgrade OTA with minimal changes and risk.
Old apps will continue to work as expected.
For the new apps to work we will need a component which does the appropriate adjustments. The component itself will do very little. It will check if there is a partition table in sector 2 at offset X, X to be determined. if not - copies the current rBoot config and adds the new partition table in sector 2 with offset X. This is the most critical operation as there can be power failure after the second sector is cleared and before the new content is written. After powering on rBoot will generate a standard rBoot config which should work for most of the applications. So such a risk should be limited to small amount of devices.
This component can be enabled by default for all ESP8266 applications. And it should be possible to disable it, if request.
The execution of the component should happen before init()
.
rBoot and PT contain certain information that can be found in both. It will be better:
This is the most critical operation as there can be power failure after the second sector is cleared and before the new content is written.
Actually, we wouldn't need to erase the sector first as the area should already be blank - so little risk attached. BUT subsequent OTA updates wishing to switch ROMS would need to clear the sector so it then becomes an issue.
This component can be enabled by default for all ESP8266 applications. And it should be possible to disable it, if request. The execution of the component should happen before
init()
.
Keeping the rBoot config and partition table in the same sector is bad as subsequent OTA updates risk losing both rBoot config AND PT.
We could keep the PT in the boot sector. Offset 0x0C00, for example, allows 32 partitions with plenty of space for the boot code. This would avoid the risk of erasing the partition table sector when performing subsequent OTA updates.
Aside: Generally, the partition table should be fixed at deployment and updating it via OTA should rarely be required. However, a safer way to to this might involve reserving two sectors for the partition table, using the second as a backup. OTA updating the boot sector should be avoided if at all possible!
Losing 4Kbytes of program space from 1MB is a non-issue. Keeping a compatible layout to support OTA updating is valuable though.
It is currently a requirement that the partition table is located immediately after the boot sector. Moving all the configuration partitions to the start of flash is, IMHO, preferable for the best user experience, so is the most sensible default setup.
However, relaxing this restriction for the ESP8266 (and Host) would eliminate the above complications. Therefore, I propose the following changes:
legacy
configurations, e.g. legacy-1m
, legacy-4m
.
These can be used to create a 4.2-compatible layout.
The flash size is important of course because it determines where the configuration sectors are.The OTA update procedure is:
legacy
configuration.
e.g. "base_config": "legacy-4m"
.
I've opened this issue to discuss how OTA (over-the-air) upgrading of existing ESP8266 devices might work when migrating to the new partition-table structure.
With partition tables the ESP8266 layout has necessarily been altered. See https://sming.readthedocs.io/en/latest/upgrading/4.2-4.3.html.
Re-flashing a device to 4.3 should be as simple as:
I've used the Microsoft (TM) Notepad+Pencil App to illustrate some scenarios. On the left are the flash sector numbers (easier than writing addresses).
(1) This is a typical layout for Sming 4.2 devices:
(2) This is the new default layout for Sming 4.3:
The closest we can to the previous layout is shown in (3). There is a further development that could be made to the framework by allowing the partition table to share the boot sector, shown in (4).