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

[Eric Nelson <eric.nelson@boundarydevices.com>]

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@boundarydevices.com
> <mailto:eric.nelson@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 :)

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.

>
>
>         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.

Regards,


Eric