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. If static dtbs are not enough for your requirements look at device overlay trees. Best regards Heinrich Schuchardt _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
