[U-Boot] [PATCH 12/31] board_f: Add new function to allow runtime DTB selection

From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 12/31] board_f: Add new function to allow runtime DTB selection
Date: Fri, 10 Mar 2017 10:42:48 -0500	[thread overview]
Message-ID: <20170310154248.GD19897@bill-the-cat> (raw)
In-Reply-To: <20170309211256.23e3227a@jawa>

On Thu, Mar 09, 2017 at 09:12:56PM +0100, Lukasz Majewski wrote:
> On Thu, 9 Mar 2017 08:08:20 -0500
> Tom Rini <trini@konsulko.com> wrote:
> 
> > On Thu, Mar 02, 2017 at 01:04:16PM -0600, Franklin S Cooper Jr wrote:
> > 
> > > Runtime U-boot dtb selection is generally a two step process. First
> > > step is to simply use an initial generic dtb. The second step is to
> > > select the dtb and perhaps execute additional code ones U-boot
> > > knows what board it is running on. Embedded_dtb_select handles the
> > > second step by allowing board specific code to run and perform what
> > > ever necessary configuration that is needed.
> > 
> > So I'm not 100% sure on how to proceed here exactly.  We have a few
> > things to consider.  First, I bet the generic dtb is good enough for
> > loading up and booting to Linux (and loading/passing a different,
> > complete and board specific DTB).  Second, we have the (reasonable)
> > set of patches and discussion to make the DTB that we use available
> > easily so that it could be passed on to Linux (or EFI apps or
> > whatever). So, this is probably the right thing to do in the long
> > run, but is also another data point in the "but we need to think and
> > talk about if some platforms really shouldn't be shipping their full
> > FT on the HW somewhere".
> 
> It might also happen that somebody would like to have one "blessed"
> u-boot binary stored in one place and then only change u-boot DTB stored
> on another memory region (like eMMC, NOR).
> 
> The above also seems like a valid use case, especially when one wants to
> support device for a long time (many DTBs) and avoid uncontrolled grown
> of final u-boot.img binary size (as this is now the case for TI).

I'd rather stress that the problem is that when we want to support N
boards and we do that by including N device tree blobs, the size is
going to grow with each board.  What's not happening yet is the DTB is
being stored in the device and accessed that way.  I'd really like to
see some boards moving in that direction.  And it seems like perhaps
you're working on some that could?  Thanks!

-- 
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/20170310/b556d77c/attachment.sig>