Talk:PineTime external flash partitioning
From JF:
In my opinion, we should draw a hard line between the bootloader and the application firmwares.
Bootloader
The bootloader cannot fail. If it fails, the device is bricked. One way to achieve this is to make it as simple as possible. If the bootloader have to take a partition table into account, it also have to handle degraded cases : it's got corrupted by a bug in a firmware, bad crc, incorrect offset/size mentionned,... It turns out that the bootloader cannot recover from these degraded cases. Taking the partition table into account just adds some code (retrieve the partition table, search for partitions, process CRC, handles error codes,...) that will not be complete : there's no way we will write something meaningful in this code, for example:
if(!check_crc(&data)) {
// ???
}
Why not assume the data is where we expect it to be and coherent? The result will be the same : if the data is OK, it works, if the data is corrupt... the bootloader cannot do anything. Handling the partition table just gives the bootloader more chances to fail.
With that in mind, I'm still convinced that the bootloader should just look for its data at fixed and hardcoded values :
- bootloader code : internal flash 0 -> 0x7000
- primary slot : internal flash 0x8000 -> 0x7f000
- scratch : internal flash : 0x7f000 -> 0x80000
- factory firmware : external flash 0 -> 0x40000
- secondary slot : external flash 0x40000 -> 0xb4000
There's no point to change these values : the internal flash is 100% allocated, the reloader cannot handle firmwares > ~180kB and the secondary slot must be the same size as the primary slot.
The only shared knowledge between the bootloader and the application firmwares is that the application must be linked at offset 0x8000, should copy the OTA image in external flash at offset 0x40000, can use the external flash from offset 0xb4000 and must refresh the watchdog periodically.
Application
The application firmwares, on the other side, can be more flexible, and a common partitioning scheme can have some sense if multiple firmware developers agree to implement it. They would have to agree on a partition table scheme, file system, file formats,... That won't be easy, but that's possible. In this case, the partition table can be stored in the FS section at offset 0xb4000, and the bootloader won't have any knowledge of it. As the external spi memory flash is mostly unused (to my knowledge, only wasp-os uses it), everything is still possible on that part of the memory.
But... do we really need to share data between multiple firmwares installation? Let's compare with the PinePhone : when you install a new OS image on the EMMC or on the SD card, the user settings (wifi password, timezone, applications,...) won't be kept. If the user wants to keep files in the process, they have to backup them manually (on the SD card or on a computer) before flashing the new firmware and then restore them manually.
Why would we want to solve issues that even more complex devices do not solve? Even Windows have a hard-time upgrading major versions of the OS while keeping applications and users settings untouched.
Yet, this is still possible to do, but I wonder how firmwares will actually integrate this partition table? How will they know that they can use and existing partition or create a new one? What if there is not enough space available for the firmware you've just installed?