Difference between revisions of "PineTime bootloader improvements"

Jump to navigation Jump to search
(Add bootloader/application boundaries)
Line 81: Line 81:
== Discussions ==  
== Discussions ==  
=== Boot Logo : embedded into the bootloader binary vs stored in the external SPI flash ===
=== Boot Logo : embedded into the bootloader binary vs stored in the external SPI flash ===
Embedding (and compressing) the boot logo inside the bootloader binary brings many advantages:
* All the data are available in memory at runtime. No need to load them & check them, and no need to handle errors and invalid corrupted data.
* The data is available and can be sent directly to the display controller
* 1 unique logo for the bootloader : easier to document and explain to the user that this specific logo is the logo from the bootloader mode.
But it also has some disadvantages:
* 1-Bit RLE encoding (very effective compression) allows only 2 colors (background/foreground)
* The boot logo cannot be customized (unless you recompile and flash this new build of the bootloader)
* The size of the boot logo is limited (depending on the compression ratio)
My (JF) point is that the bootloader must be as reliable as possible. I would like to remove all part of the code than can fail. If we read the boot logo from the SPI flash, we will write something like this:
<nowiki>int ret;
boot_logo_info info;
ret = SpiNor_read(infoOffset, &info, sizeof(boot_logo_info));
if(ret != 0) {
  // Something went wrong while reading image info
  panic(); // ? reset ?
}
if(check_boot_logo_info(info) == false) {
  // image info are invalid (ex : size > 240*240), we cannot use them
  panic(); // ? reset ? Display nothing?
}
...
</nowiki>
We could find invalid image info if a firmware did not respect the memory map and erased/overwrote the external memory map. In this case, the bootloader couldn't run properly.
Of course, we can implement something smart in panic() (retry, use failover values,...), but again, this adds complexity and bug probability.
All these if's that call panic() can be avoided by using hard-coded values at build-time.
If the image is hard-coded, you won't be able to easily (not that easy, actually...) customize the boot logo. But remember that this logo is only display for a short time only when the device reset (manually or during an OTA).


=== Fixed vs dynamic memory map ===
=== Fixed vs dynamic memory map ===