summaryrefslogtreecommitdiff
path: root/cmd/nvedit_efi.c
AgeCommit message (Collapse)Author
2020-05-18command: Remove the cmd_tbl_t typedefSimon Glass
We should not use typedefs in U-Boot. They cannot be used as forward declarations which means that header files must include the full header to access them. Drop the typedef and rename the struct to remove the _s suffix which is now not useful. This requires quite a few header-file additions. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18common: Drop uuid.h from common headerSimon Glass
Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-07efi_loader: use logical and in do_env_print_efi()Heinrich Schuchardt
If we want to check if two booleans are true, we should use a logical conjunction (&&) and not a bitwise and-operator (&). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-04-16cmd: env: add "-at" option to "env set -e" commandAKASHI Takahiro
With "-at" option, EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS will be passed to SetVariable() to authenticate the variable. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16cmd: env: use appropriate guid for authenticated UEFI variableAKASHI Takahiro
A signature database variable is associated with a specific guid. For convenience, if user doesn't supply any guid info, "env set|print -e" should complement it. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2019-10-30cmd: env: extend "env [set|print] -e" to manage UEFI variablesAKASHI Takahiro
With this patch, when setting UEFI variable with "env set -e" command, we will be able to - specify vendor guid with "-guid guid", - specify variable attributes, BOOTSERVICE_ACCESS, RUNTIME_ACCESS, respectively with "-bs" and "-rt", - append a value instead of overwriting with "-a", - use memory as variable's value instead of explicit values given at the command line with "-i address,size" If guid is not explicitly given, default value will be used. Meanwhile, "env print -e," will be modified so that it will NOT dump a variable's value if '-n' is specified. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-10-06cmd: env: fix a typo in a comment of do_env_set_efi()AKASHI Takahiro
A wrong function name is referred to in a comment of do_env_set_efi(). Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-08-11env: Move env_set() to env.hSimon Glass
Move env_set() over to the new header file. Acked-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Simon Glass <sjg@chromium.org>
2019-06-04cmd: env: add -nv option for UEFI non-volatile variableAKASHI Takahiro
With this option, -nv, at "setenv -e" command, a variable will be defined as non-volatile. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-06-04cmd: env: print a message when setting UEFI variable failedAKASHI Takahiro
Error message will alert a user that setting/deleting a variable failed. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-02efi_loader: memory leak in append valueHeinrich Schuchardt
When printing an UEFI variable an error may arise while converting an illegal hexadecimal value. In this case a buffer is leaked. Close the memory leak. Provide an error message. Reported-by: Coverity (CID 185830) Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-03-20efi_loader: memory leak in efi_dump_single_var()Heinrich Schuchardt
A misplaced return statement lead to a memory leak in efi_dump_single_var(). Reported-by: Coverity (CID 185829) Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-02-25cmd: env: add "-e" option for handling UEFI variablesAKASHI Takahiro
"env [print|set] -e" allows for handling uefi variables without knowing details about mapping to corresponding u-boot variables. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>