[U-Boot] [PATCH v2 14/21] efi_loader: efi variable support

[Rob Clark]

On Tue, Sep 12, 2017 at 8:30 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Rob,
>
> On 10 September 2017 at 05:21, Rob Clark <robdclark at gmail.com> wrote:
>> Add EFI variable support, mapping to u-boot environment variables.
>> Variables are pretty important for setting up boot order, among other
>> things.  If the board supports saveenv, then it will be called in
>> ExitBootServices() to persist variables set by the efi payload.  (For
>> example, fallback.efi configuring BootOrder and BootXXXX load-option
>> variables.)
>>
>> Variables are *not* currently exposed at runtime, post ExitBootServices.
>> On boards without a dedicated device for storage, which the loaded OS
>> is not trying to also use, this is rather tricky.  One idea, at least
>> for boards that can persist RAM across reboot, is to keep a "journal"
>> of modified variables in RAM, and then turn halt into a reboot into
>> u-boot, plus store variables, plus halt.  Whatever the solution, it
>> likely involves some per-board support.
>>
>> Mapping between EFI variables and u-boot variables:
>>
>>   efi_$guid_$varname = {attributes}(type)value
>>
>> For example:
>>
>>   efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
>>      "{ro,boot,run}(blob)0000000000000000"
>>   efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
>>      "(blob)00010000"
>>
>> The attributes are a comma separated list of these possible
>> attributes:
>>
>>   + ro   - read-only
>>   + boot - boot-services access
>>   + run  - runtime access
>>
>> NOTE: with current implementation, no variables are available after
>> ExitBootServices, and all are persisted (if possible).
>>
>> If not specified, the attributes default to "{boot}".
>>
>> The required type is one of:
>>
>>   + utf8 - raw utf8 string
>>   + blob - arbitrary length hex string
>>
>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>> ---
>>  cmd/bootefi.c                 |   4 +
>>  include/efi.h                 |  19 +++
>>  include/efi_loader.h          |  10 ++
>>  lib/efi_loader/Makefile       |   2 +-
>>  lib/efi_loader/efi_boottime.c |   6 +
>>  lib/efi_loader/efi_runtime.c  |  17 ++-
>>  lib/efi_loader/efi_variable.c | 335 ++++++++++++++++++++++++++++++++++++++++++
>>  7 files changed, 388 insertions(+), 5 deletions(-)
>>  create mode 100644 lib/efi_loader/efi_variable.c
>
> What does hex2mem() do? Please add a comment
>
> This code looks fine but we need a simple way to test it. I think
> Herinrich is working on a single hello world test. That could be
> enhanced to set and read variables.

tbh, just starting Shell.efi, let alone launching SCT.efi, requires
all of this stuff (filesys, variables, installing/removing protocols,
etc) to be working

Getting shell.efi into travis and running a couple "simple" commands
seems like a better option.

BR,
-R