All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/4] efi_loader: use efi_start_image() for bootefi
Date: Thu, 18 Jul 2019 10:39:57 +0200 (CEST)	[thread overview]
Message-ID: <5438c1db9647d8f4@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <20190718060016.GA73593@largo.jsg.id.au> (message from Jonathan Gray on Thu, 18 Jul 2019 16:00:16 +1000)

> Date: Thu, 18 Jul 2019 16:00:16 +1000
> From: Jonathan Gray <jsg@jsg.id.au>
> 
> On Fri, Feb 08, 2019 at 07:46:49PM +0100, Heinrich Schuchardt wrote:
> > Remove the duplicate code in efi_do_enter() and use efi_start_image() to
> > start the image invoked by the bootefi command.
> > 
> > Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > ---
> > v2
> > 	use EFI_CALL
> 
> This commit broke booting OpenBSD/armv7 kernels on mx6cuboxi with U-Boot
> releases after 2019.01.  2019.04 works if this commit is reverted.  With
> 2019.07 there are conflicts trying to revert it and it is still broken
> as released.
> 
> f69d63fae281ba98c3d063097cf4e95d17f3754d is the first bad commit
> commit f69d63fae281ba98c3d063097cf4e95d17f3754d
> Author: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Date:   Wed Dec 26 13:28:09 2018 +0100
> 
>     efi_loader: use efi_start_image() for bootefi
>     
>     Remove the duplicate code in efi_do_enter() and use efi_start_image() to
>     start the image invoked by the bootefi command.
>     
>     Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> 
>  cmd/bootefi.c                 | 22 +---------------------
>  include/efi_loader.h          |  4 ++++
>  lib/efi_loader/efi_boottime.c |  6 +++---
>  3 files changed, 8 insertions(+), 24 deletions(-)

Hi Jonathan,

With this commit the OpenBSD bootloader (an EFI application) still
boots, but the loaded OpenBSD kernel doesn't isn't it?

I bet the problem here is that efi_start_image() sets
efi_is_direct_boot to false, which means that efi_exit_caches() which
runs as a result of calling ExitBootServices() no longer
flushes/disables the caches on 32-bit ARM.

We have been here before.  It really isn't possible to flush/disable
the L2 cache on most 32-bit ARM implementations without SoC-specific
code.  And having such code in the early kernel bootstrap code isn't
really possible.

The comments in the code suggest that loading an EFI Linux kernel
directly from U-Boot somehow works without flushing the caches.  But I
don't understand how.  But I'm pretty sure this change break booting
non-EFI Linux kernels through grub on 32-bit ARM platforms as well.

The UEFI spec has the following text (UEFI 2.5 section 2.3.5 "AArch32
Platforms"):

  Implementations of boot services will enable architecturally
  manageable caches and TLBs i.e., those that can be managed directly
  using CP15 operations using mechanisms and procedures defined in the
  ARM Architecture Reference Manual. They should not enable caches
  requiring platform information to manage or invoke non-architectural
  cache/TLB lockdown mechanisms

This suggests that the real problem here is that U-Boot enables the L2
cache on i.MX6 which violates the spec.  But things will probably run
notably slower without the L2 cache enabled.  Maybe the answer is to
just flush/disable the L2 cache when ExitBootServices() is called?


> > ---
> >  cmd/bootefi.c                 | 22 +---------------------
> >  include/efi_loader.h          |  4 ++++
> >  lib/efi_loader/efi_boottime.c |  6 +++---
> >  3 files changed, 8 insertions(+), 24 deletions(-)
> > 
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 7f9913c0ee..a2d38256e9 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -133,20 +133,6 @@ done:
> >  	return ret;
> >  }
> >  
> > -static efi_status_t efi_do_enter(
> > -			efi_handle_t image_handle, struct efi_system_table *st,
> > -			EFIAPI efi_status_t (*entry)(
> > -				efi_handle_t image_handle,
> > -				struct efi_system_table *st))
> > -{
> > -	efi_status_t ret = EFI_LOAD_ERROR;
> > -
> > -	if (entry)
> > -		ret = entry(image_handle, st);
> > -	st->boottime->exit(image_handle, ret, 0, NULL);
> > -	return ret;
> > -}
> > -
> >  /*
> >   * efi_carve_out_dt_rsv() - Carve out DT reserved memory ranges
> >   *
> > @@ -315,13 +301,7 @@ static efi_status_t do_bootefi_exec(void *efi,
> >  
> >  	/* Call our payload! */
> >  	debug("%s: Jumping to 0x%p\n", __func__, image_obj->entry);
> > -
> > -	if (setjmp(&image_obj->exit_jmp)) {
> > -		ret = image_obj->exit_status;
> > -		goto err_prepare;
> > -	}
> > -
> > -	ret = efi_do_enter(&image_obj->header, &systab, image_obj->entry);
> > +	ret = EFI_CALL(efi_start_image(&image_obj->header, NULL, NULL));
> >  
> >  err_prepare:
> >  	/* image has returned, loaded-image obj goes *poof*: */
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 3ce43f7a6f..512880ab8f 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -320,6 +320,10 @@ efi_status_t efi_create_handle(efi_handle_t *handle);
> >  void efi_delete_handle(efi_handle_t obj);
> >  /* Call this to validate a handle and find the EFI object for it */
> >  struct efi_object *efi_search_obj(const efi_handle_t handle);
> > +/* Start image */
> > +efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle,
> > +				    efi_uintn_t *exit_data_size,
> > +				    u16 **exit_data);
> >  /* Find a protocol on a handle */
> >  efi_status_t efi_search_protocol(const efi_handle_t handle,
> >  				 const efi_guid_t *protocol_guid,
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index 7a61a905f4..6c4e2f82ba 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -1770,9 +1770,9 @@ error:
> >   *
> >   * Return: status code
> >   */
> > -static efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle,
> > -					   efi_uintn_t *exit_data_size,
> > -					   u16 **exit_data)
> > +efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle,
> > +				    efi_uintn_t *exit_data_size,
> > +				    u16 **exit_data)
> >  {
> >  	struct efi_loaded_image_obj *image_obj =
> >  		(struct efi_loaded_image_obj *)image_handle;
> > -- 
> > 2.20.1
> > 
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

  reply	other threads:[~2019-07-18  8:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08 18:46 [U-Boot] [PATCH v2 0/4] efi_loader: rework loading and starting of images Heinrich Schuchardt
2019-02-08 18:46 ` [U-Boot] [PATCH v2 1/4] efi_loader: LoadImage: always allocate new pages Heinrich Schuchardt
2019-02-08 18:46 ` [U-Boot] [PATCH v2 2/4] efi_loader: set entry point in efi_load_pe() Heinrich Schuchardt
2019-02-08 18:46 ` [U-Boot] [PATCH v2 3/4] efi_loader: use efi_start_image() for bootefi Heinrich Schuchardt
2019-07-18  6:00   ` Jonathan Gray
2019-07-18  8:39     ` Mark Kettenis [this message]
2019-07-18  9:16       ` Jonathan Gray
2019-07-18 17:33         ` Heinrich Schuchardt
2019-07-18 17:40           ` Alexander Graf
2019-07-18 17:45             ` Heinrich Schuchardt
2019-07-18 18:50           ` Alexander Graf
2019-07-18 23:07             ` Mark Kettenis
2019-07-19  5:43               ` Heinrich Schuchardt
2019-07-19  6:14                 ` Jonathan Gray
2019-07-19 17:52                   ` Heinrich Schuchardt
2019-07-19 18:36                     ` Heinrich Schuchardt
2019-02-08 18:46 ` [U-Boot] [PATCH v2 4/4] efi_loader: clean up bootefi_test_prepare() Heinrich Schuchardt

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=5438c1db9647d8f4@bloch.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --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.