On Tue, Sep 12, 2017 at 8:30 AM, Simon Glass <s...@chromium.org> wrote:
> Hi Rob,
>
> On 10 September 2017 at 05:21, Rob Clark <robdcl...@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 <robdcl...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
