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 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.
It looks like this is not a regression from the latest changes to the
kernel builder. Testing on top of ffdba8fecb
exhibits the same issue.
This change works around the issue by doing it with one invocation of
`make`, rather than doing it twice.
It has not been figured out at which exact version of the kernel this
stops being an issue, and if it is an issue from mainline Linux
outright, or something that came from Android-specific modifications.
Though it has been verified that for 3.18, both Qualcomm and Mediatek
source trees exhibit the same issue.
Fixes#216
