On 9/11/19 8:14 AM, AKASHI Takahiro wrote:
Heinrich,
On Fri, Aug 23, 2019 at 08:42:27AM +0900, AKASHI Takahiro wrote:
On Thu, Aug 22, 2019 at 07:53:46PM +0200, Heinrich Schuchardt wrote:
On 8/22/19 11:03 AM, AKASHI Takahiro wrote:
Heinrich,
I'm now wondering whether LoadedImage's LoadOptions, which comes
>from "bootargs" variable, should contain a command(application) name
as a first argument or not.
When I tried some efi application (efitools), I found that it expected
so. For example, efitools' UpdateVars.efi takes
Usage: UpdateVars.efi: [-g guid] [-a] [-e] [-b] var file
and I had to passed arguments by specifying "foo db DB.auth" for
"bootargs" where foo makes no sense.
What do you think about this issue?
Do you relate to
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git?
Yes.
This style of parsing LoadOptions is defined by the EFI shell. See
function ParseCommandLineToArgs() in
ShellPkg/Application/Shell/ShellParametersProtocol.c.
So do you mean that Shell.efi is responsible for adding a command name
to LoadOptions (or bootargs) as a first parameter or that LoadOptions
is solely for Shell environment?
LoadOptions are used to communicate with any EFI binary including the
Linux kernels. Inside the EFI shell Shell.efi takes care of passing the
executable name as a first parameter.
If a user chooses to call an EFI binary which expects its own name as
first parameter via bootefi, the user should simply add it to
LoadOptions via 'setenv bootargs'.
I would not change anything in bootefi. Otherwise you start passing
'vmlinux' or 'grubaa64.efi' as command line arguments to Linux.
Best regards
Heinrich
If so, should we do the same thing at bootefi?
Any comment?
-Takahiro Akashi
If UpdateVars.efi would work differently it could not be launched via
the shell.
Well, I'm trying to run UpdateVars.efi in a standalone way
by invoking it directly from bootefi/bootmgr and it obviously fails
due to this issue.
Thanks,
-Takashiro Akashi
Best regards
Heinrich
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
