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

[Franklin S Cooper Jr]

On 03/10/2017 09:42 AM, Tom Rini wrote:
> 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 at 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!

The problem I see is storing dtbs that U-boot needs as part of booting
at a different location requires alot of guarantees across all the evms
being supported by the single image. If for NAND boot one board stores
U-boot's dtb blobs in one partition vs another then things fall apart.
The larger this minimal dtb is the harder it is to guarantee that it
will be valid in the future when/if new boards are introduced or reved.

The benefit of having a dtb bundled in the U-boot image is that no
matter the boot mode or board differences as long as something loads
U-boot it can then select the proper dtb to use from memory. I think I
remember Andrew also saying how having U-boot's dtbs built in will make
things easier in the HS world.

Now the method that U-boot is loaded and where U-boot is stored will
need to deal with U-boots larger size. But I think its rather enviable
since atleast for TI evms we kept space allowance for U-boot in NOR and
NAND rather small for no real reason.

In general if someone adds support and makes use of using a minimal
U-boot dtb and loading the "correct" one from some other location I
wouldn't have an issue with that. But atleast to me I don't think that
is the direction for TI evms.
>