Discussion
Today I'll resume studying Papyrix's boot sequence, having gone on a tangent about how it renders text & other things. I explored it now because Papyrix might init this text-rendering early to display error messages.
If it does successfully init SD card access it'll check if that SD card contains a software-update to install! Installing it involves retrieving a singleton to which it passes the file, invokes a beginUpdate() method & displays update text, removes the file, & maybe restarts.
1/?
After that the caller repeatedly invokes the pump() method which verifies its in the "flashing" state & that an abort wasn't requested, checks whether we've finished & if so closes the file whilst setting the new boot partition, considers erasing some of the target partition, reads more of the file, & writes it to that partition. Cleaning up after any errors.
There's also setter for an abort flag, & a routine to reset various properties to default.
3/4!
Looking at dependencies of the display logic... Aside from the graphics APIs I've already explored there's a somewhat meaningless conversion from a bool to an enum, alongside which are defined the values to be rendered. Including 2 lines of text stating:
"Firmware update in progress
Do not power off"
The display is sent into "deep sleep" once its displaying this message, though there's a flag for not doing so.
4/4 Fin for today! Tomorrow: Settings!
I won't study ESP32's update APIs.
Install bonfire.cafe
Get the full app experience
That singleton class has a verifying-setter for which file to install. There's a method to verifying that the configured file is of a certain size-range & has a valid header + (using mbedtls library) hash.
A beginUpdate method retrieves the next update partition, invokes that validation routine, opens the file, sets some properties, & sets a current state for whether this all process succeeded. If so the caller will display the emergency update screen.
2/3?