On 06/25/2017 02:12 PM, Rob Clark wrote: > On Sun, Jun 25, 2017 at 1:06 AM, Heinrich Schuchardt <xypron.g...@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? Regards Heinrich > Also it would be nice for debugging if initial > value of grub's debug env var could be read from EFI. For both these > cases, read-only access and no runtime access would be sufficient. > And from an implementation standpoint, that seemed like a reasonable > first goal. > > BR, > -R > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
