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 === |