public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox