All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Tom Rini <trini@konsulko.com>
Cc: Zhiqiang Hou <Zhiqiang.Hou@nxp.com>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	u-boot@lists.denx.de, priyanka.jain@nxp.com
Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Date: Thu, 22 Jul 2021 19:00:31 +0200	[thread overview]
Message-ID: <20890af388806b4bead24e9a10532305@walle.cc> (raw)
In-Reply-To: <20210722152622.GY9379@bill-the-cat>

Am 2021-07-22 17:26, schrieb Tom Rini:
> On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
> 
>> From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
>> 
>> The feature BOOTENV_SHARED_EFI is not supported on layerscape
>> boards, it didn't result kernel boot crash previously since
>> there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of
>> 'boot_efi_binary'.
>> 
>> But since the commit f3866909e350 ("distro_bootcmd: call EFI
>> bootmgr even without having /EFI/boot"), it will cause kernel
>> boot crash as there isn't a valid fdt_addr and it finially uses
>> the device tree blob of U-Boot and further cause errors.
>> 
>> As this feature is enabled by default for armv7 and armv8, so
>> disable it explicitly to avoid calling the 'scan_dev_for_efi'.
> 
> I'm not thrilled with this.  Why isn't the solution to get and keep in
> sync the device trees, so that the tree U-Boot has is valid for the
> kernel?  I'm also open to discussing f3866909e350 more.  But I'm really
> opposed to disabling EFI_LOADER on modern platforms as that will make
> adoption of U-Boot in device harder I feel.

I don't know whats going on with the NXP boards, but the sl28
is a layerscape board it is working pretty well with EFI boot.

So why don't you fix the root cause instead of disabling this
feature?

-michael

  reply	other threads:[~2021-07-22 17:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-22  6:25 [PATCH] configs: layerscape: Disable the EFI_LOADER feature Zhiqiang Hou
2021-07-22 15:26 ` Tom Rini
2021-07-22 17:00   ` Michael Walle [this message]
2021-07-22 17:02     ` Tom Rini
2021-07-22 17:08       ` Michael Walle
2021-07-22 17:21         ` Tom Rini
2021-07-22 17:09     ` Fabio Estevam
2021-07-26  7:10       ` Z.Q. Hou
2021-07-26  7:01     ` Z.Q. Hou
2021-07-26  7:12       ` Michael Walle
2021-07-26  7:37         ` Z.Q. Hou
2021-07-26 12:28           ` Tom Rini
2021-07-27  5:42             ` Z.Q. Hou
2021-07-27 13:07               ` Tom Rini
2021-07-28  8:24                 ` Z.Q. Hou
2021-08-03 14:52           ` Mian Yousaf Kaukab
2021-08-12  6:15             ` Z.Q. Hou
2021-07-26  6:18   ` Z.Q. Hou
2021-07-26  6:30     ` Michael Walle
2021-07-26 12:23     ` Tom Rini

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=20890af388806b4bead24e9a10532305@walle.cc \
    --to=michael@walle.cc \
    --cc=Zhiqiang.Hou@nxp.com \
    --cc=priyanka.jain@nxp.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.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.