The hardware boot order on all platforms is: FSPI->EMMC->SD->USB.
U-Boot SPL (our chainloader), however, is told by its DTB to boot in
this order: SD->EMMC->FSPI. It then populates `RkAtagTypeBootDev` with
the device it decided to boot from. We use this information to determine
the drive we belong to, in order to write the variable store there.
While this behavior is useful for testing, it should generally be
avoided because it bypasses the SPL version we intended to ship with
UEFI, which could lead to all sorts of issues.
One such issue is that some SPL builds (namely Orange Pi's) flashed to
SPI will happily boot from SD card while setting the ATAG to EMMC
instead. Obviously, this leads UEFI to use the wrong device (or none at
all if EMMC is missing) for writing variables. Since SPL only reads the
variable store into memory from the actual boot device (SD card),
settings will not persist.
To address this, we'll no longer rely on that ATAG unless it indicates
FSPI boot, in which case it would most likely be correct due to FSPI
having priority in hardware - well, assuming there no further broken
SPLs in the wild that might set it to FSPI while booting from SD :P.
Instead, we'll look through the SD->EMMC devices (same order as SPL) to
find a FIT image matching our own, indicating that's likely the boot
device.
Signed-off-by: Mario Bălănică <mariobalanica02@gmail.com>
When a keyboard gets installed after connecting the USB controller
handles, ConPlatformDxe will check that its short-form device path
exists in the ConIn variable before enabling input from it.
This variable is missing at first boot, so adding the path after the
keyboard was already ignored means it won't be usable during BDS
countdown.
Signed-off-by: Mario Bălănică <mariobalanica02@gmail.com>
Firstly, split up the Dw8250 serial lib into "full" and "debug"
versions. The full version is only used at SEC phase (PrePi) for setting
the specified baud rate, while the debug one is used everywhere else and
cannot reinitialize the UART.
To read the baud rate NV variable in SEC, introduce BaseVariableLib,
which is just a slightly modified FaultTolerantWritePei + VariablePei to
not use HOBs and PPIs, since they're not available this early.
Previous boot stages (DDR, TF-A, U-Boot SPL) are still hardcoded to
output at 1.5 Mbaud.
Signed-off-by: Mario Bălănică <mariobalanica02@gmail.com>
During DXE phase, the LED will pulse repeatedly. If this keeps going on forever
or the LED freezes, something went terribly wrong.
After the console is ready, at BDS phase, the LED will switch to a calm short
pulsing every two seconds or so. This indicates the firmware is alive and
waiting for user input or the countdown to boot automatically. If the blinking
stops, it can either mean that the firmware has exited the boot services and
handed off control to the OS (most likely), or that it's not responding. Brief
freezes are expected with some peripherals due to how device drivers use the
timer.
I had initially planned on blinking the LED at ExitBootServices() too, but the
delay added to the boot process doesn't seem justified.
Long pulses >= 2 are reserved for future error code reporting.
Enabled on all platforms that have a controllable LED.
Rockchip EVB platforms and RK356x silicon bits have also been deleted.
1) EVB platform was outdated, unbuildable and I don't have the hardware to test. Feel free to add it back if you do :-)
2) RK356x support was almost non-existent outside of some basic HAL SDK ported code.
There's no interest to support it in this repo either - unless, of course, it's done properly with code reusability in mind (but then might as well aim for upstream).
This fixes:
- USB 1.1 devices (keyboard) not working until the BDS timeout
- NVRAM vars on SD/eMMC not being dumped in time when the boot process isn't interrupted
