All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] efi_loader: Fall back to fdtfile naming convention
Date: Thu, 14 Apr 2016 15:46:42 +0200	[thread overview]
Message-ID: <570F9F42.50304@suse.de> (raw)
In-Reply-To: <570F9E84.9030205@suse.de>

On 04/14/2016 03:43 PM, Andreas F?rber wrote:
> Am 13.04.2016 um 23:22 schrieb Alexander Graf:
>> When there is no $fdtfile variable set, we still have a good chance
>> that on 32bit arm the fdtfile really is just called $soc-$board.dtb.
>>
>> Enable the exports for $soc and $board in our distr defaults and make
>> use of them in the efi boot script.
>>
>> Reported-by: Andreas Faerber <afaerber@suse.de>
>> Reported-by: Stephen Warren <swarren@wwwdotorg.org>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>>   include/config_distro_bootcmd.h  | 24 +++++++++++++++++++++---
>>   include/config_distro_defaults.h |  1 +
>>   2 files changed, 22 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
>> index 67eb8f2..eaaf2cc 100644
>> --- a/include/config_distro_bootcmd.h
>> +++ b/include/config_distro_bootcmd.h
>> @@ -99,6 +99,21 @@
>>   #endif
>>   
>>   #ifdef BOOTEFI_NAME
>> +#if defined(CONFIG_ARM) && !defined(CONFIG_ARM64)
>> +/*
>> + * On 32bit ARM systems there is a reasonable number of systems that follow
>> + * the $soc-$board$boardver.dtb name scheme for their device trees. Use that
>> + * scheme if we don't have an explicit fdtfile variable.
>> + */
> Why limit this to 32-bit? If fdtfile is not set and we drop the
> limitation above, then for CONFIG_ARM64 (and theoretically MIPS) we
> could add the vendor subdir to our prefixes. Even without the latter it
> does no harm, your config_distro_defaults.h change below does not seem
> to be limited to ARM anyway.

For ARM64 the pattern doesn't work because of the subdirectories, so 
we'll have to have a separate block that takes the soc vendor name into 
account as well. Does MIPS use dtb these days?

>
>> +#define BOOTENV_EFI_SET_FDTFILE_FALLBACK                                  \
>> +	"if test -z \"${fdtfile}\" -a -n \"${soc}\"; then "               \
>> +	  "setenv efifdtfile ${soc}-${board}${boardver}.dtb; "            \
> Please consistently use efi_ for readability.
>
> The logic looks slightly weird on first sight, being separated from the
> below context. Can't we just set fdtfile here if unset and drop the four
> extra lines below? Once boot has executed, there may be leftover
> variables such as filesize anyway.

The problem is that the boot may fail - and in that case you would have 
a potentially invalid fdtfile variable.


Alex

  reply	other threads:[~2016-04-14 13:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13 21:22 [U-Boot] [PATCH 1/2] efi_loader: Pass fdt address directly to bootefi cmd Alexander Graf
2016-04-13 21:22 ` [U-Boot] [PATCH 2/2] efi_loader: Fall back to fdtfile naming convention Alexander Graf
2016-04-13 23:24   ` Stephen Warren
2016-04-14 13:53     ` Alexander Graf
2016-04-14 13:43   ` Andreas Färber
2016-04-14 13:46     ` Alexander Graf [this message]
2016-04-13 22:26 ` [U-Boot] [PATCH 1/2] efi_loader: Pass fdt address directly to bootefi cmd Andreas Färber
2016-04-13 22:41   ` Alexander Graf
2016-04-13 23:20 ` Stephen Warren
2016-04-14 13:48   ` Alexander Graf
2016-04-14 15:27     ` Stephen Warren

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=570F9F42.50304@suse.de \
    --to=agraf@suse.de \
    --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.