[U-Boot] [PATCH RESEND 2/2] cmd: fdt: add fdt overlay application subcommand

[Pantelis Antoniou]

Hi Tom,

> On Apr 13, 2016, at 22:42 , Tom Rini <trini at konsulko.com> wrote:
> 
> On Fri, Apr 08, 2016 at 04:29:40PM -0500, Rob Herring wrote:
>> On Tue, Apr 5, 2016 at 5:03 PM, Pantelis Antoniou
>> <pantelis.antoniou at konsulko.com> wrote:
>>> Hi Maxime,
>>> 
>>>> On Apr 4, 2016, at 11:25 , Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
>>>> 
>>>> The device tree overlays are a good way to deal with user-modifyable
>>>> boards or boards with some kind of an expansion mechanism where we can
>>>> easily plug new board in (like the BBB or the raspberry pi).
>>>> 
>>>> However, so far, the usual mechanism to deal with it was to have in Linux
>>>> some driver detecting the expansion boards plugged in and then request
>>>> these overlays using the firmware interface.
>>>> 
>>>> That works in most cases, but in some cases, you might want to have the
>>>> overlays applied before the userspace comes in. Either because the new
>>>> board requires some kind of an early initialization, or because your root
>>>> filesystem is accessed through that expansion board.
>>>> 
>>>> The easiest solution in such a case is to simply have the component before
>>>> Linux applying that overlay, removing all these drawbacks.
>>>> 
>> 
>> [...]
>> 
>>>> diff --git a/cmd/fdt_overlay.c b/cmd/fdt_overlay.c
>>> 
>>> This looks it’s general libfdt code.
>>> It should end up in libfdt/ so that others can use it, and eventually
>>> be pushed upstream.
>> 
>> +1. It really needs to go into libfdt first to avoid any re-licensing issues.
>> 
>> Another option which Grant has suggested would be to extend the FDT
>> format to include overlays as a whole. Then the kernel can apply them
>> during unflattening. This would simplify things on the bootloader
>> side.
> 
> Perhaps in some cases?  Part of the overall use case here is that
> something has to dynamically grab the N overlays that apply on the
> current hardware and make them available.  So the bootloader would still
> need to grab them and pass along to the kernel to apply.  And I've
> already received some pushback on saying it could wait until
> initrd/initramfs.
> 

There are a number of options about what to do.

This patch is made for a specific case of DRM drivers not handling overlays.
I expect this is because the DRM device core does not have a reconfig notifier.
I plan adding it when I get my CHIP setup.

Grant’s option is to have the kernel do the overlay application by appending
the overlay dtbos after the base tree blob. 

This patch is orthogonal to both, so let’s review and make up our minds on the
updated patch.

> -- 
> Tom

Regards

— Pantelis