From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
Mark Kettenis <kettenis@openbsd.org>
Subject: Re: [PATCH v2 2/2] bootstd: Replicate the dtb-filename quirks of distroboot
Date: Mon, 30 Jan 2023 12:10:39 -0500 [thread overview]
Message-ID: <Y9f6D/Tc9jVPL714@bill-the-cat> (raw)
In-Reply-To: <20230129012715.83657-2-sjg@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]
On Sat, Jan 28, 2023 at 06:27:15PM -0700, Simon Glass wrote:
> For EFI, the distro boot scripts search in three different directories
> for the .dtb file. The SOC-based filename fallback is supported only for
> 32-bit ARM.
>
> Adjust the code to mirror this behaviour.
>
> Also some boards can use a prior-stage FDT if one is not found in the
> normal way. Support this and show a warning in that case.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Suggested-by: Mark Kettenis <kettenis@openbsd.org>
> ---
>
> Changes in v2:
> - Allow use of the prior-stage FDT if nothing else is found
> - Warn about using a prior-stage FDT
>
> boot/bootflow.c | 3 ++
> boot/bootmeth_efi.c | 70 +++++++++++++++++++++++++++++++++++++++------
> include/bootflow.h | 14 +++++++++
> 3 files changed, 78 insertions(+), 9 deletions(-)
>
> diff --git a/boot/bootflow.c b/boot/bootflow.c
> index 4999018e36e..5ee12eb2bab 100644
> --- a/boot/bootflow.c
> +++ b/boot/bootflow.c
> @@ -463,6 +463,9 @@ int bootflow_run_boot(struct bootflow_iter *iter, struct bootflow *bflow)
>
> printf("** Booting bootflow '%s' with %s\n", bflow->name,
> bflow->method->name);
> + if (IS_ENABLED(CONFIG_OF_HAS_PRIOR_STAGE) &&
> + (bflow->flags & BOOTFLOWF_USE_PRIOR_FDT))
> + printf("** Warning: Using prior-stage device tree\n");
It should not be a warning. It should just be a statement. It's not an
inherent failure or problem, but it is something the user should be
aware of as it may be unexpected. Or simply because they should be just
as aware here as when it's loaded from $file at $location. A huge
general stumbling block when working on custom / new hardware is "did
the device tree I want really get used?" so being clear where the one
being used is from is important.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2023-01-30 17:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-29 1:27 [PATCH v2 1/2] bootflow: Rename bootflow_flags_t Simon Glass
2023-01-29 1:27 ` [PATCH v2 2/2] bootstd: Replicate the dtb-filename quirks of distroboot Simon Glass
2023-01-30 17:10 ` Tom Rini [this message]
2023-02-07 4:02 ` Simon Glass
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=Y9f6D/Tc9jVPL714@bill-the-cat \
--to=trini@konsulko.com \
--cc=kettenis@openbsd.org \
--cc=sjg@chromium.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