[U-Boot] [PATCH 4/6] efi_loader: Improve .dtb search for arm64

[Tom Rini]

On Tue, Jul 12, 2016 at 05:59:58PM +0200, Andreas Färber wrote:
> Am 12.07.2016 um 16:50 schrieb Tom Rini:
> > On Tue, Jul 12, 2016 at 06:21:45AM +0200, Andreas Färber wrote:
> > 
> >> On arm64 Linux device trees are organized by SoC vendor. Therefore we
> >> need to search the vendor subdirectory as well.
> >>
> >> Since the SoC vendor may be different from ${vendor}, introduce a new
> >> ${soc_vendor}. If this is not set, the behavior remains unchanged.
> >>
> >> Cc: Alexander Graf <agraf at suse.de>
> >> Signed-off-by: Andreas Färber <afaerber at suse.de>
> >> ---
> >>  include/config_distro_bootcmd.h | 18 +++++++++++++++++-
> >>  1 file changed, 17 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
> >> index eadec2e..8f14457 100644
> >> --- a/include/config_distro_bootcmd.h
> >> +++ b/include/config_distro_bootcmd.h
> >> @@ -113,6 +113,15 @@
> >>  #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
> >>  #endif
> >>  
> >> +#if defined(CONFIG_ARM64)
> >> +#define BOOTENV_EFI_SET_FDTFILE_VENDOR                                    \
> >> +	"if test -n \"${soc_vendor}\"; then "                             \
> >> +		"setenv efi_dtb_vendor_prefix ${soc_vendor}/; "           \
> >> +	"fi; "
> >> +#else
> > 
> > OK.  Looking at the current Linux kernel, it's a given that for arm64 a
> > DTB will be in a subdirectory, always.  Perhaps we should fix this in
> > Kconfig and have... CONFIG_FDTFILE_VENDOR_DIRECTORY and set this
> > correctly per vendor (and yes, eventually there will be some "fun" as
> > NXP boards will sometimes be in freescale/ and sometimes nxp/ so maybe
> > try and futureproof ourselves so that we loop over this variable) ?
> 
> Yes, it's a given that in the kernel the .dts is always in a vendor
> subdirectory - as listed in an earlier thread also for mips etc.

Right, OK.  And it will be extra fun later on when arm and powerpc
(probably) switch over.

> And yes, it's also true that due to our scripted openSUSE packaging we
> therefore install .dtb to /boot/dtb-foo/vendor/ - but that's not
> guaranteed for other distros and users, is it? Therefore I include "" in
> the loop further down.

It feels unlikely that other distributions would unroll the directories
that exist already upstream.

> Anyway, adding a config option sounds good. Will you look into that
> yourself or should I do that as part of this series?

Please re-work the series around this idea.

> I had considered the ambiguous vendor case and am iterating over
> $efi_dtb_vendor_prefix in a list of vendors already below, only the
> addition of the trailing slash above is limiting us to one currently. Do
> you have a concrete suggestion of how to make that more flexible?

The more I think about it, the less worried I am about it, actually.
Lets just assume that we will have the right vendor set and if it turns
out that a 'git mv' is done for say freescale later on down the line,
we'll worry about it then.  Unless someone knows about how it might go
and wants to speak up now?  York?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160712/a2dccad0/attachment.sig>