Hi,
On 5/22/23 06:01, Neal Gompa wrote:
On Mon, May 22, 2023 at 6:57 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
Hi,
But could we use U-Boot to fill in this gap so these systems still
work? We'd then treat x86 like ARM (if no UEFI, use U-Boot UEFI).
How does u-boot handle EFI variables in that case?
Unless the variable store is disabled, I believe it's written to a
file? That seems to be how it works on ARM.
Usually with u-boot the runtime service is simply unavailable, which
tends to break all kinds of things in subtle ways.
More recently though there have been patches merged to support runtime
services in the uboot/uefi shim by trapping to lower level firmware
which has always had runtime components available (unlike uboot), ex
PSCI. So, if you have runtime variable storage with uboot its most
likely being handled by Trusted Firmware A
(https://www.trustedfirmware.org/).
That said TFA has all the same problems as EDK2 on some of these
platforms WRT variable storage because its not generally possible to
share something like an emmc/etc device between the Linux kernel and the
firmware. Meaning the firmware needs to have a dedicated device, used to
store the variables. Usually some SPI flash, but not always. I don't
think anyone has managed to get a workable runtime service that writes
the variable store to a file on a shared FS outside of maybe some tech
demos. The problem is that the low level firmware need to understand and
be able to read/write something like the ESP + USB/SD/MMC and then
release it while keeping a volatile copy around long enough for a OS
specific service to then take over persistence of the data. Its brittle
and OS dependent as every single OS in existence then needs to have the
service ported and active. The closest solutions I'm aware of are things
like the older rpi3 EDK2 ports which wrote the variable store back to
the firmware image itself on the ESP. But this doesn't really provide
non-volatile runtime storage either because power loss/whatever causes
updates done while the OS is running to be lost. It also technically
violates the relevant specs as well since it fails to be "tamperproof" .
So "hardware bug", but once you fix all those bugs, it becomes
straightforward just to toss TFA + EDK2 on it and run a full blown UEFI
implementation providing all the infrastructure to make things like
secure/measured boot, firmware updates, persistent variables, TRNGs,
RTCs, etc all "just work". And then once all that works, it becomes
possible to consider ACPI in the same bucket and avoid a bunch of kernel
drivers for clock, power, battery, thermal, etc management.
How does u-boot do storage access in that case? Go call BIOS INT13h?
Or use its own device drivers?
Last time I checked there have been a few gaps, no virtio-scsi driver
for example.
I don't know. I imagine with U-Boot using a similar build process to
the kernel that it does have its own equivalent of drivers for
platform configuration.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
