On Sun, Jun 25, 2017 at 5:07 PM, Heinrich Schuchardt <xypron.g...@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.g...@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.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? >>> >> >> 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
