[U-Boot] [RFC] Remove static display data

[Simon Glass]

Hi Eric,

On Sun, Jul 28, 2013 at 1:22 PM, Eric Nelson <
eric.nelson at boundarydevices.com> wrote:

> Hi Simon,
>
>
> On 07/28/2013 11:09 AM, Simon Glass wrote:
>
>> Hi Eric,
>>
>> On Sun, Jul 28, 2013 at 10:57 AM, Eric Nelson
>> <eric.nelson at boundarydevices.**com <eric.nelson at boundarydevices.com>
>> <mailto:eric.nelson@**boundarydevices.com<eric.nelson at boundarydevices.com>>>
>> wrote:
>>
>>     On our boards, we store the environment in SPI-NOR, but in a separate
>>     8k block.
>>
>>     I presume the "bound" fdt will be stored immediately after U-Boot,
>>     which will move around a bit as the code changes.
>>
>> Yes - it would be nice to have an option to put the FDT anywhere, but
>> that is not supported at present. Even better if SPL could load it.
>> Better again if U-Boot plus its FDTs could be a FIT image and SPL could
>> load that and select the correct FDT.
>>
>>
> That's a whole bunch of TLAs :)
>

Sorry, I mean:

FDT - flat device tree
SPL - secondary program loader - the little thing that loads U-Boot
FIT - flat image tree - a type of file that can hold multiple
kernels/FDTs/ramdisks that can be selected at boot


> I don't see any major blockers in any of these, though our immediate
> goals are much more modest:
>         - put display configuration into a read/write spot, and
>         - allow users to specify resolutions for HDMI and timing
>         information for new panels
>
> If we can just parse block(s) of DT text, then update or append
> that to the kernel FDT, I think we can meet our needs.


Sounds good.

>
>
>
>>
>>         The FDT is normally stored immediately after U-Boot, but I
>>         suppose we
>>         could add an option for the FDT to live elsewhere, or perhaps be
>>         loaded
>>         from flash live the environment. Actually the latter is already
>>         possible
>>         by reading the new FDT into RAM in your boot script, and making
>>         U-Boot
>>         use it, something like:
>>
>>         sf probe
>>         sf read <addr> ...
>>         fdt addr -c <addr>
>>
>>     At the moment, we intend to normally load the FDT from the same media
>>     as the kernel for a couple of reasons:
>>
>>              - It's not needed at all for non-Linux uses (we support
>> Windows
>>              Embedded, QNX, et cetera)
>>
>>              - We'll likely need separate FDTs for different boards which
>>              can execute the same U-Boot binary (Nitrogen6x, SABRE Lite)
>>              unless we can figure out a way to place small conditionals
>>              in the FDT
>>
>> We attach a kernel FDT to the kernel image. Passing U-Boot's FDT to the
>> kernel is an option that I haven't explored, and is probably only
>> possible if it can be updated.
>>
>>
> I'm coming at this from the other direction: I've only seen how to
> load FDT from secondary storage and hand it to the kernel with bootm.
>

That's easy - just put it in a FIT. Then you can package the kernel and
various FDTs into that FIT, use bootm to load it.

If you do enable CONFIG_OF_CONTROL, then also enable CONFIG_FIT_BEST_MATCH
- it will choose the correct one for the kernel based on U-Boot's
compatible information. Then the FDT selection becomes automatic.


>
> Regards,
>
>
> Eric
>

Regards,
Simon