On Sun, Jun 25, 2017 at 5:07 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/25/2017 09:06 PM, Rob Clark wrote:
On Sun, Jun 25, 2017 at 1:16 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/25/2017 02:12 PM, Rob Clark wrote:
On Sun, Jun 25, 2017 at 1:06 AM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06/25/2017 12:29 AM, Rob Clark wrote:
Mapping from EFI variables to grub variables. Still almost as many TODOs as lines of code, but just figured I'd send out an early version for comments.
I was thinking of it as a useful way for u-boot to pass values to grub (although grub is still missing a way for grub scripts to retrieve UEFI variables).
The rough idea is to encode GUID + variable name plus "efi_" prefix (to avoid unintended u-boot variables leaking into the UEFI world). And then encode the type (and attributes?) in the string value of the variable. Ie. something like:
setenv efi_8be4df6193ca11d2aa0d00e098032b8c_OsIndicationsSupported (u64)0
Hello Rob,
thank you for your effort for a first implementation of EFI variables.
The UEFI variable runtime services consists of the following functions: GetVariable, GetNextVariableName, SetVariable, QueryVariableInfo.
SetVariable is meant to persistently store variables. The value has to be maintained across reboots.
A variable consists of a variable name, a vendor GUID, an attribute bitmask and the variable value.
SetVariable has to support appending to the value.
The UEFI spec also defines some global variables marked by the EFI_GLOBAL_VARIABLE GUID.
Grub uses UEFI variables to store boot entries for GPT disks.
To do so it requires that the EFI runtime services are available after Linux is booted.
This is somewhat more ambitious than what I had in mind, at least for the first step or two. By the time linux is loaded, most of u-boot has disappeared from memory, so currently there is very little it can provide as far as runtime services. (I was thinking read-only access to variables might be possible as a 2nd step.)
otoh, at least for systems that have 1+gb of RAM, u-boot is relatively tiny, so a build option to keep all of u-boot in RAM after boot might be a way to approach this.
So my conclusion is that it would be valuable to implement the EFI variable services. This implementation has to include a persistent store. The runtime service has to be available after Linux boot.
It would be nice, and it'd make u-boots implementation (approximation?) of EFI somewhat more complete, for sure.
If we want to manipulate variables from U-Boot we would need two new commands to set and get EFI variable names, GUIDs, attributes, and values.
hmm.. the approach of encoding GUID in variable name and attributes as part of the string value would mean normal getenv/setenv is all we need. This seemed like a more natural approach to me.
Could you, please, provide your use case for manipulating EFI variables from U-Boot.
One use case I could think of is to let Linux write the dtb name into an EFI variable and let U-Boot read this EFI variable to decide which dtb file to load.
I was kinda thinking in the opposite direction, for u-boot to expose dtb name to grub.
The dtb is passed to EFI in memory (2nd parameter of bootefi). So why should grub need the dtb name?
because I want to be able to update dtb w/ 'dnf upgrade' (or equiv cmd for other distros).. the alternative seems to be figuring out how (via distro u-boot script) to find the most recent dtb, or constantly requiring users to upgrade their firmware. Neither of which sounds appealing.
(the whole idea of a single static dtb for a SoC is nice in theory until you realize that complex SoC's like snapdragon are still pushing the boundaries of what we have figured out how to model in dt)
BR, -R
Have a look at Debian/Ubuntu package flash-kernel.
After installing a new kernel update-initramfs triggers flash-kernel. flash-kernel looks up the value provided by file /proc/device-tree/model in a database file to find the correct dtb and installs it in /boot. It further sets a symbolic link /boot/dtb to the dtb. So u-boot can simply load /boot/dtb and pass it to grub.
but this doesn't work if you want to be able to (for example) unplug a disk from device A and plug it in to device B, does it?
If static dtbs are not enough for your requirements look at device overlay trees.
I do have some interest in overlays, mostly because currently the firmware generates psuedo-random eth/wifi/bt MAC addrs based on some board specific info (like emmc part serial #, for example).. which we currently loose out from if not using the qcom specific lk->kernel boot chain. But I guess that is a bit of a different topic.
BR, -R