public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [PATCH 02/10] efi_loader: add option to initialise EFI subsystem early
Date: Mon, 18 May 2020 10:43:03 +0900	[thread overview]
Message-ID: <20200518014303.GD6139@laputa> (raw)
In-Reply-To: <5db38095-573f-71af-cacd-e63653395fdd@gmx.de>

Heinrich,

On Sun, May 17, 2020 at 09:29:44AM +0200, Heinrich Schuchardt wrote:
> On 4/28/20 2:16 AM, AKASHI Takahiro wrote:
> > Heinrich,
> >
> > On Mon, Apr 27, 2020 at 10:09:11PM +0200, Heinrich Schuchardt wrote:
> >> On 4/27/20 11:48 AM, AKASHI Takahiro wrote:
> >>> If this option is enabled, the initialisation of UEFI subsystem will be
> >>> done as part of U-Boot initialisation.
> >>>
> >>> This feature will be utilised in implementing capsule-on-disk feature.
> >>
> >> This would mean that we allow unaligned access very early. Something
> >> Siarhei was against:
> >
> > ?
> > Even with CONFIG_EFI_CAPSULE_ON_DISK_EARLY enabled,
> > efi_init_obj_list() is called at the last of "init" list
> > and efi_launch_capsules() is called just before the main
> > command loop.
> > So "unalignment" issue won't happen.
> 
> efi_init_obj_list() is even called when booting via booti and therefore
> before a lot of other code.

How is booti related to "unalignment" issue?

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> >
> >> https://lists.denx.de/pipermail/u-boot/2018-March/324242.html
> >> https://patchwork.ozlabs.org/project/uboot/patch/20180329213350.7868-1-xypron.glpk at gmx.de/
> >>
> >> Why can't you wait with the capsule update until any command initializes
> >> the UEFI sub-system.
> >
> > This topic is the one the I mentioned in RFC's cover letter
> > and asked you for comments several time.
> > Anyway, there are a couple of reasons:
> > 1. Updated firmware may have some effects on not only UEFI
> >    subsystem but also U-Boot's other features.
> > 2. Firmware update should surely take place after reboot
> >    as UEFI specification expects.
> > 3. Firmware update should not rely on user's interactions
> >    or whatever "bootcmd" is set to.
> > 4. In case of failure of firmware update, some recovery should
> >    be automatically taken "before" the command line is handed over
> >    to users. (The feature is not implemented yet though.)
> >
> > -Takahiro Akashi
> >
> >
> >> Best regards
> >>
> >> Heinrich
> >>
> >>>
> >>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >>> ---
> >>>  common/board_r.c       | 6 ++++++
> >>>  lib/efi_loader/Kconfig | 4 ++++
> >>>  2 files changed, 10 insertions(+)
> >>>
> >>> diff --git a/common/board_r.c b/common/board_r.c
> >>> index 0bbeaa7594c6..7cf21a6078f9 100644
> >>> --- a/common/board_r.c
> >>> +++ b/common/board_r.c
> >>> @@ -64,6 +64,9 @@
> >>>  #if defined(CONFIG_GPIO_HOG)
> >>>  #include <asm/gpio.h>
> >>>  #endif
> >>> +#ifdef CONFIG_EFI_SETUP_EARLY
> >>> +#include <efi_loader.h>
> >>> +#endif
> >>>
> >>>  DECLARE_GLOBAL_DATA_PTR;
> >>>
> >>> @@ -867,6 +870,9 @@ static init_fnc_t init_sequence_r[] = {
> >>>  #endif
> >>>  #if defined(CONFIG_M68K) && defined(CONFIG_BLOCK_CACHE)
> >>>  	blkcache_init,
> >>> +#endif
> >>> +#ifdef CONFIG_EFI_SETUP_EARLY
> >>> +	(init_fnc_t)efi_init_obj_list,
> >>>  #endif
> >>>  	run_main_loop,
> >>>  };
> >>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> >>> index 1cfa24ffcf72..7cc2d940f848 100644
> >>> --- a/lib/efi_loader/Kconfig
> >>> +++ b/lib/efi_loader/Kconfig
> >>> @@ -25,6 +25,10 @@ config EFI_LOADER
> >>>
> >>>  if EFI_LOADER
> >>>
> >>> +config EFI_SETUP_EARLY
> >>> +	bool
> >>> +	default n
> >>> +
> >>>  config EFI_GET_TIME
> >>>  	bool "GetTime() runtime service"
> >>>  	depends on DM_RTC
> >>>
> >>
> 

  reply	other threads:[~2020-05-18  1:43 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27  9:48 [PATCH 00/10] efi_loader: add capsule update support AKASHI Takahiro
2020-04-27  9:48 ` [PATCH 01/10] efi_loader: disk: add efi_disk_is_system_part() AKASHI Takahiro
2020-04-27 19:57   ` Heinrich Schuchardt
2020-04-27 23:54     ` AKASHI Takahiro
2020-05-01  7:06       ` Heinrich Schuchardt
2020-05-05 22:33         ` Heinrich Schuchardt
2020-04-27  9:48 ` [PATCH 02/10] efi_loader: add option to initialise EFI subsystem early AKASHI Takahiro
2020-04-27 20:09   ` Heinrich Schuchardt
2020-04-28  0:16     ` AKASHI Takahiro
2020-05-17  7:29       ` Heinrich Schuchardt
2020-05-18  1:43         ` AKASHI Takahiro [this message]
2020-04-27  9:48 ` [PATCH 03/10] efi_loader: define UpdateCapsule api AKASHI Takahiro
2020-05-17  8:02   ` Heinrich Schuchardt
2020-05-18  1:34     ` AKASHI Takahiro
2020-04-27  9:48 ` [PATCH 04/10] efi_loader: capsule: add capsule_on_disk support AKASHI Takahiro
2020-04-27 20:28   ` Heinrich Schuchardt
2020-04-28  0:28     ` AKASHI Takahiro
2020-04-30 12:52       ` Sughosh Ganu
2020-04-30 19:51         ` Heinrich Schuchardt
2020-05-07  2:50           ` AKASHI Takahiro
2020-05-07 12:05           ` Sughosh Ganu
2020-04-27  9:48 ` [PATCH 05/10] efi_loader: capsule: add memory range capsule definitions AKASHI Takahiro
2020-04-27  9:48 ` [PATCH 06/10] efi_loader: capsule: support firmware update AKASHI Takahiro
2020-04-27  9:48 ` [PATCH 07/10] efi_loader: add simple firmware management protocol for FIT image AKASHI Takahiro
2020-04-27  9:48 ` [PATCH 08/10] cmd: add "efidebug capsule" command AKASHI Takahiro
2020-04-30 12:38   ` Sughosh Ganu
2020-05-07  1:58     ` AKASHI Takahiro
2020-04-27  9:48 ` [PATCH 09/10] tools: add mkeficapsule command for UEFI capsule update test AKASHI Takahiro
2020-04-27 20:15   ` Heinrich Schuchardt
2020-04-28  1:52     ` AKASHI Takahiro
2020-04-27  9:48 ` [PATCH 10/10] test/py: add a test for efi firmware update capsule AKASHI Takahiro
2020-04-27 20:33 ` [PATCH 00/10] efi_loader: add capsule update support Heinrich Schuchardt
2020-04-27 23:45   ` 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=20200518014303.GD6139@laputa \
    --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