On Sun, Jun 25, 2017 at 1:16 PM, Heinrich Schuchardt <[email protected]> wrote: > On 06/25/2017 02:12 PM, Rob Clark wrote: >> On Sun, Jun 25, 2017 at 1:06 AM, Heinrich Schuchardt <[email protected]> >> 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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
