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

Hi Eric,

On Sun, Jul 28, 2013 at 1:22 PM, Eric Nelson < eric.nelson@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@boundarydevices.**com eric.nelson@boundarydevices.com <mailto:eric.nelson@**boundarydevices.comeric.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 :)

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