The splash is now an application that should be started and forked from.
Once started, it will listen for messages on a ZeroMQ socket reporting
progress.
The current protocol is extremely simple, reporting (optional) label,
and reporting a progress amount.
Additionally, it responds to a string commant ("quit") to quit as
needed.
The applet is specifically written to show what we call the "recovery
menu". Yes, it's also the boot selection, but it will get confusing with
the upcoming boot tracking splash UI that's upcoming.
This is to ensure "UX-friendly" tasks gets run ASAP.
Quickly explained, this makes sure that the top tasks (e.g. Splash) gets
ran as soon as possible.
Given the list:
- Splash
- Graphics
- AAA
- BBB
- CCC
If `Graphics` ends up running, and AAA, BBB and CCC can too, Splash will
have to wait until all those tasks got ran once!
Not ideal for UX, if e.g. BBB takes time to *run* and we can't show the
progress to users!
The added cost of restarting the queue is minimal with tests I ran. It
was not more than a tenth of a second, and could even be rounding
errors.
This has not been made "fancier" for easier use yet. It is unknown how
useful updating the firmware is.
Usage:
```
$ NIXPKGS_ALLOW_UNFREE=1 nix-build --argstr device pine64-pinephone -A pkgs.pine64-pinephone.qfirehose
$ sudo ./result/bin/QFirehose -l ./ -f ./newfw
```
But maybe read more about whether you want to update or not beforehand?
https://forum.pine64.org/showthread.php?tid=11815
The following from megi's have to be disabled (not set) or else the
console logo will not show up at boot (pre-init).
> CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
> CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
This will be used by the boot GUI to only show relevant reboot options.
We might add other HAL-ish things in there.
Note that this is all internal stuff :)
We'll think it over for how we want to handle custom reboot commands,
but some platforms (e.g. u-boot, depthcharge, qemu) don't and can't use
them.
A goal is to keep stage-2 as generic as possible, so building into it
some knowledge of this is harder.
At any rate, the user can still reboot, and hold the key combo as
needed!
Ugh... The whole `''${devtype} ''${devnum}:''${bootpart}` thing was
cargo-culted from other u-boot scripts as "the way to go" to re-use the
information set by the generic distro boot...
EXCEPT that it doesn't work since 2018.
13dd6665ed
They are not environment variables since that change. So any of those
scripts end up working *by sheer luck* since it would end up booting
from the first device's first partition.
Ugh ugh ugh...
There is one **major** difference with the choice: We are now selecting
on a partition's label, rather than booting whatever is deemed bootable.
This assumes the upcoming change where we are using GPT rather than MBR.
But still, this is compatible with the default expectation from U-Boot
by falling back to the "bootable" attribute.
