2018-05-07 21:02:21 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
/*
|
|
|
|
* EFI utils
|
|
|
|
*
|
|
|
|
* Copyright (c) 2017 Rob Clark
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <malloc.h>
|
|
|
|
#include <charset.h>
|
|
|
|
#include <efi_loader.h>
|
2019-01-18 11:31:54 +00:00
|
|
|
#include <hexdump.h>
|
2019-01-21 11:43:13 +00:00
|
|
|
#include <environment.h>
|
|
|
|
#include <search.h>
|
|
|
|
#include <uuid.h>
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
|
|
|
#define READ_ONLY BIT(31)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
*
|
|
|
|
* Maybe a utf16 type would be useful to for a string value to be auto
|
|
|
|
* converted to utf16?
|
|
|
|
*/
|
|
|
|
|
2018-09-23 02:08:09 +00:00
|
|
|
#define PREFIX_LEN (strlen("efi_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx_"))
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
2019-01-18 18:52:05 +00:00
|
|
|
/**
|
|
|
|
* efi_to_native() - convert the UEFI variable name and vendor GUID to U-Boot
|
|
|
|
* variable name
|
|
|
|
*
|
|
|
|
* The U-Boot variable name is a concatenation of prefix 'efi', the hexstring
|
|
|
|
* encoded vendor GUID, and the UTF-8 encoded UEFI variable name separated by
|
|
|
|
* underscores, e.g. 'efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder'.
|
|
|
|
*
|
|
|
|
* @native: pointer to pointer to U-Boot variable name
|
|
|
|
* @variable_name: UEFI variable name
|
|
|
|
* @vendor: vendor GUID
|
|
|
|
* Return: status code
|
|
|
|
*/
|
2018-08-31 19:31:31 +00:00
|
|
|
static efi_status_t efi_to_native(char **native, const u16 *variable_name,
|
2018-12-30 19:53:51 +00:00
|
|
|
const efi_guid_t *vendor)
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
{
|
|
|
|
size_t len;
|
2018-08-31 19:31:31 +00:00
|
|
|
char *pos;
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
2018-08-31 19:31:31 +00:00
|
|
|
len = PREFIX_LEN + utf16_utf8_strlen(variable_name) + 1;
|
|
|
|
*native = malloc(len);
|
|
|
|
if (!*native)
|
|
|
|
return EFI_OUT_OF_RESOURCES;
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
2018-08-31 19:31:31 +00:00
|
|
|
pos = *native;
|
|
|
|
pos += sprintf(pos, "efi_%pUl_", vendor);
|
|
|
|
utf16_utf8_strcpy(&pos, variable_name);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2019-01-18 18:52:05 +00:00
|
|
|
/**
|
|
|
|
* prefix() - skip over prefix
|
|
|
|
*
|
|
|
|
* Skip over a prefix string.
|
|
|
|
*
|
|
|
|
* @str: string with prefix
|
|
|
|
* @prefix: prefix string
|
|
|
|
* Return: string without prefix, or NULL if prefix not found
|
|
|
|
*/
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
static const char *prefix(const char *str, const char *prefix)
|
|
|
|
{
|
|
|
|
size_t n = strlen(prefix);
|
|
|
|
if (!strncmp(prefix, str, n))
|
|
|
|
return str + n;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2019-01-18 18:52:05 +00:00
|
|
|
/**
|
|
|
|
* parse_attr() - decode attributes part of variable value
|
|
|
|
*
|
|
|
|
* Convert the string encoded attributes of a UEFI variable to a bit mask.
|
|
|
|
* TODO: Several attributes are not supported.
|
|
|
|
*
|
|
|
|
* @str: value of U-Boot variable
|
|
|
|
* @attrp: pointer to UEFI attributes
|
|
|
|
* Return: pointer to remainder of U-Boot variable value
|
|
|
|
*/
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
static const char *parse_attr(const char *str, u32 *attrp)
|
|
|
|
{
|
|
|
|
u32 attr = 0;
|
|
|
|
char sep = '{';
|
|
|
|
|
|
|
|
if (*str != '{') {
|
|
|
|
*attrp = EFI_VARIABLE_BOOTSERVICE_ACCESS;
|
|
|
|
return str;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (*str == sep) {
|
|
|
|
const char *s;
|
|
|
|
|
|
|
|
str++;
|
|
|
|
|
|
|
|
if ((s = prefix(str, "ro"))) {
|
|
|
|
attr |= READ_ONLY;
|
2019-06-04 06:52:06 +00:00
|
|
|
} else if ((s = prefix(str, "nv"))) {
|
|
|
|
attr |= EFI_VARIABLE_NON_VOLATILE;
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
} else if ((s = prefix(str, "boot"))) {
|
|
|
|
attr |= EFI_VARIABLE_BOOTSERVICE_ACCESS;
|
|
|
|
} else if ((s = prefix(str, "run"))) {
|
|
|
|
attr |= EFI_VARIABLE_RUNTIME_ACCESS;
|
|
|
|
} else {
|
|
|
|
printf("invalid attribute: %s\n", str);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
str = s;
|
|
|
|
sep = ',';
|
|
|
|
}
|
|
|
|
|
|
|
|
str++;
|
|
|
|
|
|
|
|
*attrp = attr;
|
|
|
|
|
|
|
|
return str;
|
|
|
|
}
|
|
|
|
|
2019-01-18 18:52:05 +00:00
|
|
|
/**
|
2019-06-20 10:03:53 +00:00
|
|
|
* efi_get_variable() - retrieve value of a UEFI variable
|
2019-01-18 18:52:05 +00:00
|
|
|
*
|
|
|
|
* This function implements the GetVariable runtime service.
|
|
|
|
*
|
|
|
|
* See the Unified Extensible Firmware Interface (UEFI) specification for
|
|
|
|
* details.
|
|
|
|
*
|
|
|
|
* @variable_name: name of the variable
|
|
|
|
* @vendor: vendor GUID
|
|
|
|
* @attributes: attributes of the variable
|
|
|
|
* @data_size: size of the buffer to which the variable value is copied
|
|
|
|
* @data: buffer to which the variable value is copied
|
|
|
|
* Return: status code
|
|
|
|
*/
|
2018-12-30 19:53:51 +00:00
|
|
|
efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
|
|
|
|
const efi_guid_t *vendor, u32 *attributes,
|
|
|
|
efi_uintn_t *data_size, void *data)
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
{
|
2018-08-31 19:31:31 +00:00
|
|
|
char *native_name;
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
efi_status_t ret;
|
|
|
|
unsigned long in_size;
|
|
|
|
const char *val, *s;
|
|
|
|
u32 attr;
|
|
|
|
|
2017-09-13 22:05:41 +00:00
|
|
|
EFI_ENTRY("\"%ls\" %pUl %p %p %p", variable_name, vendor, attributes,
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
data_size, data);
|
|
|
|
|
|
|
|
if (!variable_name || !vendor || !data_size)
|
|
|
|
return EFI_EXIT(EFI_INVALID_PARAMETER);
|
|
|
|
|
2018-08-31 19:31:31 +00:00
|
|
|
ret = efi_to_native(&native_name, variable_name, vendor);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
if (ret)
|
|
|
|
return EFI_EXIT(ret);
|
|
|
|
|
2019-04-04 19:36:44 +00:00
|
|
|
EFI_PRINT("get '%s'\n", native_name);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
|
|
|
val = env_get(native_name);
|
2018-08-31 19:31:31 +00:00
|
|
|
free(native_name);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
if (!val)
|
|
|
|
return EFI_EXIT(EFI_NOT_FOUND);
|
|
|
|
|
|
|
|
val = parse_attr(val, &attr);
|
|
|
|
|
|
|
|
in_size = *data_size;
|
|
|
|
|
|
|
|
if ((s = prefix(val, "(blob)"))) {
|
2019-01-18 11:31:54 +00:00
|
|
|
size_t len = strlen(s);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
2018-05-11 20:18:25 +00:00
|
|
|
/* number of hexadecimal digits must be even */
|
|
|
|
if (len & 1)
|
|
|
|
return EFI_EXIT(EFI_DEVICE_ERROR);
|
|
|
|
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
/* two characters per byte: */
|
2018-05-11 20:18:25 +00:00
|
|
|
len /= 2;
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
*data_size = len;
|
|
|
|
|
2019-05-15 17:32:43 +00:00
|
|
|
if (in_size < len) {
|
|
|
|
ret = EFI_BUFFER_TOO_SMALL;
|
|
|
|
goto out;
|
|
|
|
}
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
|
|
|
if (!data)
|
|
|
|
return EFI_EXIT(EFI_INVALID_PARAMETER);
|
|
|
|
|
2019-01-18 11:31:54 +00:00
|
|
|
if (hex2bin(data, s, len))
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
return EFI_EXIT(EFI_DEVICE_ERROR);
|
|
|
|
|
2019-04-04 19:36:44 +00:00
|
|
|
EFI_PRINT("got value: \"%s\"\n", s);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
} else if ((s = prefix(val, "(utf8)"))) {
|
|
|
|
unsigned len = strlen(s) + 1;
|
|
|
|
|
|
|
|
*data_size = len;
|
|
|
|
|
2019-05-15 17:32:43 +00:00
|
|
|
if (in_size < len) {
|
|
|
|
ret = EFI_BUFFER_TOO_SMALL;
|
|
|
|
goto out;
|
|
|
|
}
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
|
|
|
if (!data)
|
|
|
|
return EFI_EXIT(EFI_INVALID_PARAMETER);
|
|
|
|
|
|
|
|
memcpy(data, s, len);
|
|
|
|
((char *)data)[len] = '\0';
|
|
|
|
|
2019-04-04 19:36:44 +00:00
|
|
|
EFI_PRINT("got value: \"%s\"\n", (char *)data);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
} else {
|
2019-04-04 19:36:44 +00:00
|
|
|
EFI_PRINT("invalid value: '%s'\n", val);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
return EFI_EXIT(EFI_DEVICE_ERROR);
|
|
|
|
}
|
|
|
|
|
2019-05-15 17:32:43 +00:00
|
|
|
out:
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
if (attributes)
|
|
|
|
*attributes = attr & EFI_VARIABLE_MASK;
|
|
|
|
|
2019-05-15 17:32:43 +00:00
|
|
|
return EFI_EXIT(ret);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
}
|
|
|
|
|
2019-01-21 11:43:13 +00:00
|
|
|
static char *efi_variables_list;
|
|
|
|
static char *efi_cur_variable;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* parse_uboot_variable() - parse a u-boot variable and get uefi-related
|
|
|
|
* information
|
|
|
|
* @variable: whole data of u-boot variable (ie. name=value)
|
|
|
|
* @variable_name_size: size of variable_name buffer in byte
|
|
|
|
* @variable_name: name of uefi variable in u16, null-terminated
|
|
|
|
* @vendor: vendor's guid
|
|
|
|
* @attributes: attributes
|
|
|
|
*
|
|
|
|
* A uefi variable is encoded into a u-boot variable as described above.
|
|
|
|
* This function parses such a u-boot variable and retrieve uefi-related
|
|
|
|
* information into respective parameters. In return, variable_name_size
|
|
|
|
* is the size of variable name including NULL.
|
|
|
|
*
|
|
|
|
* Return: EFI_SUCCESS if parsing is OK, EFI_NOT_FOUND when
|
|
|
|
the entire variable list has been returned,
|
|
|
|
otherwise non-zero status code
|
|
|
|
*/
|
|
|
|
static efi_status_t parse_uboot_variable(char *variable,
|
|
|
|
efi_uintn_t *variable_name_size,
|
|
|
|
u16 *variable_name,
|
|
|
|
const efi_guid_t *vendor,
|
|
|
|
u32 *attributes)
|
|
|
|
{
|
|
|
|
char *guid, *name, *end, c;
|
|
|
|
unsigned long name_len;
|
|
|
|
u16 *p;
|
|
|
|
|
|
|
|
guid = strchr(variable, '_');
|
|
|
|
if (!guid)
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
guid++;
|
|
|
|
name = strchr(guid, '_');
|
|
|
|
if (!name)
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
name++;
|
|
|
|
end = strchr(name, '=');
|
|
|
|
if (!end)
|
|
|
|
return EFI_INVALID_PARAMETER;
|
|
|
|
|
|
|
|
name_len = end - name;
|
|
|
|
if (*variable_name_size < (name_len + 1)) {
|
|
|
|
*variable_name_size = name_len + 1;
|
|
|
|
return EFI_BUFFER_TOO_SMALL;
|
|
|
|
}
|
|
|
|
end++; /* point to value */
|
|
|
|
|
|
|
|
/* variable name */
|
|
|
|
p = variable_name;
|
|
|
|
utf8_utf16_strncpy(&p, name, name_len);
|
|
|
|
variable_name[name_len] = 0;
|
|
|
|
*variable_name_size = name_len + 1;
|
|
|
|
|
|
|
|
/* guid */
|
|
|
|
c = *(name - 1);
|
|
|
|
*(name - 1) = '\0'; /* guid need be null-terminated here */
|
|
|
|
uuid_str_to_bin(guid, (unsigned char *)vendor, UUID_STR_FORMAT_GUID);
|
|
|
|
*(name - 1) = c;
|
|
|
|
|
|
|
|
/* attributes */
|
|
|
|
parse_attr(end, attributes);
|
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2019-01-18 18:52:05 +00:00
|
|
|
/**
|
2019-01-21 11:43:13 +00:00
|
|
|
* efi_get_next_variable_name() - enumerate the current variable names
|
|
|
|
* @variable_name_size: size of variable_name buffer in byte
|
|
|
|
* @variable_name: name of uefi variable's name in u16
|
|
|
|
* @vendor: vendor's guid
|
2019-01-18 18:52:05 +00:00
|
|
|
*
|
2019-01-21 11:43:13 +00:00
|
|
|
* This function implements the GetNextVariableName service.
|
2019-01-18 18:52:05 +00:00
|
|
|
*
|
|
|
|
* See the Unified Extensible Firmware Interface (UEFI) specification for
|
2019-01-21 11:43:13 +00:00
|
|
|
* details: http://wiki.phoenix.com/wiki/index.php/
|
|
|
|
* EFI_RUNTIME_SERVICES#GetNextVariableName.28.29
|
2019-01-18 18:52:05 +00:00
|
|
|
*
|
2019-01-21 11:43:13 +00:00
|
|
|
* Return: status code
|
2019-01-18 18:52:05 +00:00
|
|
|
*/
|
2018-05-17 05:57:05 +00:00
|
|
|
efi_status_t EFIAPI efi_get_next_variable_name(efi_uintn_t *variable_name_size,
|
|
|
|
u16 *variable_name,
|
2018-12-30 19:53:51 +00:00
|
|
|
const efi_guid_t *vendor)
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
{
|
2019-01-21 11:43:13 +00:00
|
|
|
char *native_name, *variable;
|
|
|
|
ssize_t name_len, list_len;
|
|
|
|
char regex[256];
|
|
|
|
char * const regexlist[] = {regex};
|
|
|
|
u32 attributes;
|
|
|
|
int i;
|
|
|
|
efi_status_t ret;
|
|
|
|
|
2017-09-13 22:05:41 +00:00
|
|
|
EFI_ENTRY("%p \"%ls\" %pUl", variable_name_size, variable_name, vendor);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
2019-01-21 11:43:13 +00:00
|
|
|
if (!variable_name_size || !variable_name || !vendor)
|
2019-03-19 17:36:21 +00:00
|
|
|
return EFI_EXIT(EFI_INVALID_PARAMETER);
|
2019-01-21 11:43:13 +00:00
|
|
|
|
|
|
|
if (variable_name[0]) {
|
|
|
|
/* check null-terminated string */
|
|
|
|
for (i = 0; i < *variable_name_size; i++)
|
|
|
|
if (!variable_name[i])
|
|
|
|
break;
|
|
|
|
if (i >= *variable_name_size)
|
|
|
|
return EFI_EXIT(EFI_INVALID_PARAMETER);
|
|
|
|
|
|
|
|
/* search for the last-returned variable */
|
|
|
|
ret = efi_to_native(&native_name, variable_name, vendor);
|
|
|
|
if (ret)
|
|
|
|
return EFI_EXIT(ret);
|
|
|
|
|
|
|
|
name_len = strlen(native_name);
|
|
|
|
for (variable = efi_variables_list; variable && *variable;) {
|
|
|
|
if (!strncmp(variable, native_name, name_len) &&
|
|
|
|
variable[name_len] == '=')
|
|
|
|
break;
|
|
|
|
|
|
|
|
variable = strchr(variable, '\n');
|
|
|
|
if (variable)
|
|
|
|
variable++;
|
|
|
|
}
|
|
|
|
|
|
|
|
free(native_name);
|
|
|
|
if (!(variable && *variable))
|
|
|
|
return EFI_EXIT(EFI_INVALID_PARAMETER);
|
|
|
|
|
|
|
|
/* next variable */
|
|
|
|
variable = strchr(variable, '\n');
|
|
|
|
if (variable)
|
|
|
|
variable++;
|
|
|
|
if (!(variable && *variable))
|
|
|
|
return EFI_EXIT(EFI_NOT_FOUND);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
*new search: free a list used in the previous search
|
|
|
|
*/
|
|
|
|
free(efi_variables_list);
|
|
|
|
efi_variables_list = NULL;
|
|
|
|
efi_cur_variable = NULL;
|
|
|
|
|
|
|
|
snprintf(regex, 256, "efi_.*-.*-.*-.*-.*_.*");
|
|
|
|
list_len = hexport_r(&env_htab, '\n',
|
|
|
|
H_MATCH_REGEX | H_MATCH_KEY,
|
|
|
|
&efi_variables_list, 0, 1, regexlist);
|
2019-01-22 19:10:46 +00:00
|
|
|
/* 1 indicates that no match was found */
|
|
|
|
if (list_len <= 1)
|
2019-01-21 11:43:13 +00:00
|
|
|
return EFI_EXIT(EFI_NOT_FOUND);
|
|
|
|
|
|
|
|
variable = efi_variables_list;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = parse_uboot_variable(variable, variable_name_size, variable_name,
|
|
|
|
vendor, &attributes);
|
|
|
|
|
|
|
|
return EFI_EXIT(ret);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
}
|
|
|
|
|
2019-01-18 18:52:05 +00:00
|
|
|
/**
|
2019-06-20 10:03:53 +00:00
|
|
|
* efi_set_variable() - set value of a UEFI variable
|
2019-01-18 18:52:05 +00:00
|
|
|
*
|
|
|
|
* This function implements the SetVariable runtime service.
|
|
|
|
*
|
|
|
|
* See the Unified Extensible Firmware Interface (UEFI) specification for
|
|
|
|
* details.
|
|
|
|
*
|
|
|
|
* @variable_name: name of the variable
|
|
|
|
* @vendor: vendor GUID
|
|
|
|
* @attributes: attributes of the variable
|
|
|
|
* @data_size: size of the buffer with the variable value
|
|
|
|
* @data: buffer with the variable value
|
|
|
|
* Return: status code
|
|
|
|
*/
|
2018-12-30 19:53:51 +00:00
|
|
|
efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
|
|
|
|
const efi_guid_t *vendor, u32 attributes,
|
2018-12-30 20:03:15 +00:00
|
|
|
efi_uintn_t data_size, const void *data)
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
{
|
2018-08-31 19:31:31 +00:00
|
|
|
char *native_name = NULL, *val = NULL, *s;
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
efi_status_t ret = EFI_SUCCESS;
|
|
|
|
u32 attr;
|
|
|
|
|
2018-05-17 05:57:05 +00:00
|
|
|
EFI_ENTRY("\"%ls\" %pUl %x %zu %p", variable_name, vendor, attributes,
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
data_size, data);
|
|
|
|
|
2019-05-24 06:59:02 +00:00
|
|
|
/* TODO: implement APPEND_WRITE */
|
2019-06-12 21:28:42 +00:00
|
|
|
if (!variable_name || !*variable_name || !vendor ||
|
|
|
|
((attributes & EFI_VARIABLE_RUNTIME_ACCESS) &&
|
|
|
|
!(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)) ||
|
2019-05-24 06:59:02 +00:00
|
|
|
(attributes & EFI_VARIABLE_APPEND_WRITE)) {
|
2018-08-31 19:31:31 +00:00
|
|
|
ret = EFI_INVALID_PARAMETER;
|
|
|
|
goto out;
|
|
|
|
}
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
2018-08-31 19:31:31 +00:00
|
|
|
ret = efi_to_native(&native_name, variable_name, vendor);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
if (ret)
|
2018-08-31 19:31:31 +00:00
|
|
|
goto out;
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
|
|
|
#define ACCESS_ATTR (EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_BOOTSERVICE_ACCESS)
|
|
|
|
|
|
|
|
if ((data_size == 0) || !(attributes & ACCESS_ATTR)) {
|
|
|
|
/* delete the variable: */
|
|
|
|
env_set(native_name, NULL);
|
2018-08-31 19:31:31 +00:00
|
|
|
ret = EFI_SUCCESS;
|
|
|
|
goto out;
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
val = env_get(native_name);
|
|
|
|
if (val) {
|
|
|
|
parse_attr(val, &attr);
|
|
|
|
|
2019-05-24 06:59:03 +00:00
|
|
|
/* We should not free val */
|
|
|
|
val = NULL;
|
2018-08-31 19:31:31 +00:00
|
|
|
if (attr & READ_ONLY) {
|
|
|
|
ret = EFI_WRITE_PROTECTED;
|
|
|
|
goto out;
|
|
|
|
}
|
2019-05-24 06:59:03 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* attributes won't be changed
|
|
|
|
* TODO: take care of APPEND_WRITE once supported
|
|
|
|
*/
|
|
|
|
if (attr != attributes) {
|
|
|
|
ret = EFI_INVALID_PARAMETER;
|
|
|
|
goto out;
|
|
|
|
}
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
}
|
|
|
|
|
2019-06-04 06:52:06 +00:00
|
|
|
val = malloc(2 * data_size + strlen("{ro,run,boot,nv}(blob)") + 1);
|
2018-10-02 03:30:05 +00:00
|
|
|
if (!val) {
|
|
|
|
ret = EFI_OUT_OF_RESOURCES;
|
|
|
|
goto out;
|
|
|
|
}
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
|
|
|
s = val;
|
|
|
|
|
2019-01-18 18:52:05 +00:00
|
|
|
/*
|
|
|
|
* store attributes
|
|
|
|
* TODO: several attributes are not supported
|
|
|
|
*/
|
2019-06-04 06:52:06 +00:00
|
|
|
attributes &= (EFI_VARIABLE_NON_VOLATILE |
|
|
|
|
EFI_VARIABLE_BOOTSERVICE_ACCESS |
|
|
|
|
EFI_VARIABLE_RUNTIME_ACCESS);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
s += sprintf(s, "{");
|
|
|
|
while (attributes) {
|
|
|
|
u32 attr = 1 << (ffs(attributes) - 1);
|
|
|
|
|
2019-06-04 06:52:06 +00:00
|
|
|
if (attr == EFI_VARIABLE_NON_VOLATILE)
|
|
|
|
s += sprintf(s, "nv");
|
|
|
|
else if (attr == EFI_VARIABLE_BOOTSERVICE_ACCESS)
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
s += sprintf(s, "boot");
|
|
|
|
else if (attr == EFI_VARIABLE_RUNTIME_ACCESS)
|
|
|
|
s += sprintf(s, "run");
|
|
|
|
|
|
|
|
attributes &= ~attr;
|
|
|
|
if (attributes)
|
|
|
|
s += sprintf(s, ",");
|
|
|
|
}
|
|
|
|
s += sprintf(s, "}");
|
|
|
|
|
|
|
|
/* store payload: */
|
|
|
|
s += sprintf(s, "(blob)");
|
2019-01-18 17:54:26 +00:00
|
|
|
s = bin2hex(s, data, data_size);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
*s = '\0';
|
|
|
|
|
2019-04-04 19:36:44 +00:00
|
|
|
EFI_PRINT("setting: %s=%s\n", native_name, val);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
|
|
|
|
if (env_set(native_name, val))
|
|
|
|
ret = EFI_DEVICE_ERROR;
|
|
|
|
|
2018-08-31 19:31:31 +00:00
|
|
|
out:
|
|
|
|
free(native_name);
|
efi_loader: efi variable support
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>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-13 22:05:37 +00:00
|
|
|
free(val);
|
|
|
|
|
|
|
|
return EFI_EXIT(ret);
|
|
|
|
}
|
2019-06-20 10:13:05 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* efi_query_variable_info() - get information about EFI variables
|
|
|
|
*
|
|
|
|
* This function implements the QueryVariableInfo() runtime service.
|
|
|
|
*
|
|
|
|
* See the Unified Extensible Firmware Interface (UEFI) specification for
|
|
|
|
* details.
|
|
|
|
*
|
|
|
|
* @attributes: bitmask to select variables to be
|
|
|
|
* queried
|
|
|
|
* @maximum_variable_storage_size: maximum size of storage area for the
|
|
|
|
* selected variable types
|
|
|
|
* @remaining_variable_storage_size: remaining size of storage are for the
|
|
|
|
* selected variable types
|
|
|
|
* @maximum_variable_size: maximum size of a variable of the
|
|
|
|
* selected type
|
|
|
|
* Returns: status code
|
|
|
|
*/
|
|
|
|
efi_status_t __efi_runtime EFIAPI efi_query_variable_info(
|
|
|
|
u32 attributes,
|
|
|
|
u64 *maximum_variable_storage_size,
|
|
|
|
u64 *remaining_variable_storage_size,
|
|
|
|
u64 *maximum_variable_size)
|
|
|
|
{
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
}
|
2019-06-20 11:52:16 +00:00
|
|
|
|
2019-06-20 13:25:48 +00:00
|
|
|
/**
|
|
|
|
* efi_get_variable_runtime() - runtime implementation of GetVariable()
|
|
|
|
*/
|
|
|
|
static efi_status_t __efi_runtime EFIAPI
|
|
|
|
efi_get_variable_runtime(u16 *variable_name, const efi_guid_t *vendor,
|
|
|
|
u32 *attributes, efi_uintn_t *data_size, void *data)
|
|
|
|
{
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efi_get_next_variable_name_runtime() - runtime implementation of
|
|
|
|
* GetNextVariable()
|
|
|
|
*/
|
|
|
|
static efi_status_t __efi_runtime EFIAPI
|
|
|
|
efi_get_next_variable_name_runtime(efi_uintn_t *variable_name_size,
|
|
|
|
u16 *variable_name, const efi_guid_t *vendor)
|
|
|
|
{
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efi_set_variable_runtime() - runtime implementation of SetVariable()
|
|
|
|
*/
|
|
|
|
static efi_status_t __efi_runtime EFIAPI
|
|
|
|
efi_set_variable_runtime(u16 *variable_name, const efi_guid_t *vendor,
|
|
|
|
u32 attributes, efi_uintn_t data_size,
|
|
|
|
const void *data)
|
|
|
|
{
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efi_variables_boot_exit_notify() - notify ExitBootServices() is called
|
|
|
|
*/
|
|
|
|
void efi_variables_boot_exit_notify(void)
|
|
|
|
{
|
|
|
|
efi_runtime_services.get_variable = efi_get_variable_runtime;
|
|
|
|
efi_runtime_services.get_next_variable_name =
|
|
|
|
efi_get_next_variable_name_runtime;
|
|
|
|
efi_runtime_services.set_variable = efi_set_variable_runtime;
|
|
|
|
efi_update_table_header_crc32(&efi_runtime_services.hdr);
|
|
|
|
}
|
|
|
|
|
2019-06-20 11:52:16 +00:00
|
|
|
/**
|
|
|
|
* efi_init_variables() - initialize variable services
|
|
|
|
*
|
|
|
|
* Return: status code
|
|
|
|
*/
|
|
|
|
efi_status_t efi_init_variables(void)
|
|
|
|
{
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|