From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 1/5] efi_loader: bootmgr: support BootNext and BootCurrent variable behavior
Date: Wed, 27 Feb 2019 14:47:42 +0900 [thread overview]
Message-ID: <20190227054741.GB20286@linaro.org> (raw)
In-Reply-To: <8ac1f303-3130-5819-03ec-353f87908195@gmx.de>
On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > See UEFI v2.7, section 3.1.2 for details of the specification.
> >
> > With my efitool command, you can try as the following:
> > => efi boot add 1 SHELL ...
> > => efi boot add 2 HELLO ...
> > => efi boot order 1 2
> > => efi bootmgr
> > (starting SHELL ...)
> > => efi boot next 2
> > => efi bootmgr
> > (starting HELLO ...)
> > => efi dumpvar
> > <snip ...>
> > BootCurrent: {boot,run}(blob)
> > 00000000: 02 00 ..
> > BootOrder: {boot,run}(blob)
> > 00000000: 01 00 02 00 ....
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > ---
> > lib/efi_loader/efi_bootmgr.c | 34 +++++++++++++++++++++++++++++++++-
> > 1 file changed, 33 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> > index a095df3f540b..6c5303736dc6 100644
> > --- a/lib/efi_loader/efi_bootmgr.c
> > +++ b/lib/efi_loader/efi_bootmgr.c
> > @@ -145,11 +145,21 @@ static void *try_load_entry(uint16_t n, struct efi_device_path **device_path,
> > efi_deserialize_load_option(&lo, load_option);
> >
> > if (lo.attributes & LOAD_OPTION_ACTIVE) {
> > + u32 attributes;
> > efi_status_t ret;
> >
> > debug("%s: trying to load \"%ls\" from %pD\n",
> > __func__, lo.label, lo.file_path);
> >
> > + attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > + EFI_VARIABLE_RUNTIME_ACCESS;
> > + size = sizeof(n);
> > + ret = rs->set_variable(L"BootCurrent",
> > + (efi_guid_t *)&efi_global_variable_guid,
>
> Use EFI_CALL().
Okay
But as I said somewhere else, it's quite annoying to me that
some efi_xxx requires EFI_CALL(), and others not.
There should have been consistent naming rules.
> Instead of dereferencing you could directly call
> efi_set_variable().
Yeah, given that this code is under lib/efi_loader, it may be natural
to use efi_set_variable(). But existing get_var() uses the same style of coding.
Do you want to change all of the call sites including get_var()?
> > + attributes, size, &n);
> > + if (ret != EFI_SUCCESS)
> > + goto error;
> > +
> > ret = efi_load_image_from_path(lo.file_path, &image);
> >
> > if (ret != EFI_SUCCESS)
> > @@ -173,16 +183,38 @@ error:
> > void *efi_bootmgr_load(struct efi_device_path **device_path,
> > struct efi_device_path **file_path)
> > {
> > - uint16_t *bootorder;
> > + u16 bootnext, *bootorder;
> > efi_uintn_t size;
> > void *image = NULL;
> > int i, num;
> > + efi_status_t ret;
> >
> > __efi_entry_check();
> >
> > bs = systab.boottime;
> > rs = systab.runtime;
> >
> > + /* get BootNext */
> > + size = sizeof(bootnext);
> > + ret = rs->get_variable(L"BootNext",
> > + (efi_guid_t *)&efi_global_variable_guid,
> > + NULL, &size, &bootnext);
>
> You could call efi_get_variable() directly instead of dereferencing rs.
> But anyway you have to use EFI_CALL().
Ditto
> > + if (!bootnext)
> > + goto run_list;
>
> Goto is acceptable for error handling. But otherwise I would rather
> avoid it.
Okay with another indentation.
> > +
> > + /* delete BootNext */
> > + ret = rs->set_variable(L"BootNext",
> > + (efi_guid_t *)&efi_global_variable_guid,
> > + 0, 0, &bootnext);
>
> EFI_CALL().
Thanks,
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> > + if (ret != EFI_SUCCESS)
> > + goto error;
> > +
> > + image = try_load_entry(bootnext, device_path, file_path);
> > + if (image)
> > + goto error;
> > +
> > +run_list:
> > + /* BootOrder */
> > bootorder = get_var(L"BootOrder", &efi_global_variable_guid, &size);
> > if (!bootorder)
> > goto error;
> >
>
next prev parent reply other threads:[~2019-02-27 5:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-15 2:54 [U-Boot] [PATCH v2 0/5] efi_loader: run a specific efi application more easily AKASHI Takahiro
2019-01-15 2:54 ` [U-Boot] [PATCH v2 1/5] efi_loader: bootmgr: support BootNext and BootCurrent variable behavior AKASHI Takahiro
2019-02-26 18:57 ` Heinrich Schuchardt
2019-02-27 5:47 ` AKASHI Takahiro [this message]
2019-02-27 6:14 ` Heinrich Schuchardt
2019-02-27 6:27 ` AKASHI Takahiro
2019-02-27 6:39 ` Heinrich Schuchardt
2019-02-27 6:55 ` AKASHI Takahiro
2019-01-15 2:54 ` [U-Boot] [PATCH v2 2/5] efi_loader: bootmgr: allow for running a given load option AKASHI Takahiro
2019-01-15 2:54 ` [U-Boot] [PATCH v2 3/5] cmd: bootefi: carve out fdt parameter handling AKASHI Takahiro
2019-01-15 2:54 ` [U-Boot] [PATCH v2 4/5] cmd: bootefi: run an EFI application of a specific load option AKASHI Takahiro
2019-02-26 19:30 ` Heinrich Schuchardt
2019-02-27 5:58 ` AKASHI Takahiro
2019-02-27 6:31 ` Heinrich Schuchardt
2019-02-27 6:47 ` AKASHI Takahiro
2019-02-27 19:33 ` Heinrich Schuchardt
2019-02-28 4:28 ` AKASHI Takahiro
2019-02-28 4:47 ` Heinrich Schuchardt
2019-01-15 2:54 ` [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application AKASHI Takahiro
2019-02-26 19:20 ` Heinrich Schuchardt
2019-02-27 6:12 ` AKASHI Takahiro
2019-02-27 6:25 ` Heinrich Schuchardt
2019-02-27 6:37 ` AKASHI Takahiro
2019-02-27 7:10 ` Heinrich Schuchardt
2019-02-28 4:45 ` AKASHI Takahiro
2019-02-28 4:53 ` Heinrich Schuchardt
2019-02-28 5:06 ` AKASHI Takahiro
2019-02-28 5:13 ` Heinrich Schuchardt
2019-03-01 1:22 ` AKASHI Takahiro
2019-03-05 2:48 ` AKASHI Takahiro
2019-02-28 20:59 ` Heinrich Schuchardt
2019-03-01 1:26 ` AKASHI Takahiro
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=20190227054741.GB20286@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox