On Tue, Sep 12, 2017 at 8:30 AM, Simon Glass sjg@chromium.org wrote:
Hi Rob,
On 10 September 2017 at 05:21, Rob Clark robdclark@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@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