From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] efi_loader: LoadOptions (bootargs)
Date: Thu, 12 Sep 2019 09:31:41 +0900 [thread overview]
Message-ID: <20190912003139.GS4398@linaro.org> (raw)
In-Reply-To: <12b5dd0c-62ec-18cb-515b-c0fc67148a6d@gmx.de>
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
> >
>
prev parent reply other threads:[~2019-09-12 0:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 9:03 [U-Boot] efi_loader: LoadOptions (bootargs) AKASHI Takahiro
2019-08-22 17:53 ` Heinrich Schuchardt
2019-08-22 23:42 ` AKASHI Takahiro
2019-09-11 6:14 ` AKASHI Takahiro
2019-09-11 17:39 ` Heinrich Schuchardt
2019-09-12 0:31 ` AKASHI Takahiro [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190912003139.GS4398@linaro.org \
--to=takahiro.akashi@linaro.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.