efi_var_to/from_file() suggest method where variables are placed. But there is no reason for it and generic name can be used to wire also different locations for variables. Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-S905D3-CC Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Currently efi_var_file.c has functions to store/read EFI variables to/from memory buffer. These functions can be used with other EFI variable stores so move them out to efi_var_common.c Signed-off-by: Shantur Rathore <i@shantur.com> Signed-off-by: Michal Simek <michal.simek@amd.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-S905D3-CC Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Change the EFI variable load message from log_err() to log_info() with neutral wording. The previous "Failed to load" message caused customer confusion as it appeared to indicate an error condition. The efi_var_from_file() function deliberately returns EFI_SUCCESS in this case to allow the boot process to continue normally. This is documented in the function's comment block but was not reflected in the log message level or content. The message now uses informational wording to reflect that this is normal behavior when the ubootefi.var file does not yet exist. Signed-off-by: Pranav Tilak <pranav.vinaytilak@amd.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
EFI variables can be stored in a file on the EFI system partition. If that partition is missing we are writing two error messages per variable. This is too noisy. Just warn once about the missing ESP. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_var_collect() was initially placed in efi_var_file.c, since back then we only supported efi variables stored in a file. Since then we support variables stored in an RPMB as well and use that function to collect variables that should be present at runtime. So let's move it around in efi_var_common.c which makes more sense Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Ilias Apalodimas <apalos@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We largely do not need <common.h> in these files, so drop it. The only exception here is that efi_freestanding.c needs <linux/types.h> and had been getting that via <common.h>. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
It is unclear to developers why efi_var_from_file() returns EFI_SUCCESS if file ubootefi.var is missing or corrupted. Improve the description. Reported-by: Weizhao Ouyang <o451686892@gmail.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Weizhao Ouyang <o451686892@gmail.com>
When the efi subsystem starts we restore variables that are both in a file or stored into the .efi_runtime section of U-Boot. However once a variable gets created or changed the preseeded entries will end up in the file. As a consequence on the next boot we will end up adding identical variable entries twice. Fix this by checking if the to be inserted variable already exists. Also swap the restoration order and start with the file instead of the builtin variables, so a user can replace the preseeded ones if needed. Tested-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
It is volatile variables that we do not allow to be restored from file. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Use the word 'uclass' instead of 'if_type' to complete the conversion. Signed-off-by: Simon Glass <sjg@chromium.org>