Re: [U-Boot] efi_loader: LoadOptions (bootargs)
On Wed, Sep 11, 2019 at 07:39:07PM +0200, Heinrich Schuchardt wrote: > 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'. Right, but my concern is that a user normally doesn't care/know if an application expects that it would be invoked from Shell or with Shell-style arguments. > I would not change anything in bootefi. Otherwise you start passing > 'vmlinux' or 'grubaa64.efi' as command line arguments to Linux. How can users distinguish vmlinux or whatever else from other apps that would expect Shell-style arguments in general? -Takahiro Akashi > 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
Re: [U-Boot] efi_loader: LoadOptions (bootargs)
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
Re: [U-Boot] efi_loader: LoadOptions (bootargs)
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? > > 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
Re: [U-Boot] efi_loader: LoadOptions (bootargs)
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? If so, should we do the same thing at bootefi? > 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
Re: [U-Boot] efi_loader: LoadOptions (bootargs)
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? This style of parsing LoadOptions is defined by the EFI shell. See function ParseCommandLineToArgs() in ShellPkg/Application/Shell/ShellParametersProtocol.c. If UpdateVars.efi would work differently it could not be launched via the shell. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] efi_loader: LoadOptions (bootargs)
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? Thanks, -Takahiro Akashi ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
