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

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

Hi Simon,

On 07/27/2013 12:05 PM, Simon Glass wrote:
> Hi Eric,
>
> On Fri, Jul 26, 2013 at 6:42 PM, Eric Nelson
> <eric.nelson@boundarydevices.com
> <mailto:eric.nelson@boundarydevices.com>> wrote:
>
>     Thanks for the thoughtful response, Stefano.
>     On 07/26/2013 07:42 AM, Stefano Babic wrote:
>
>         Hi Eric,
>
>         On 26/07/2013 16:04, Eric Nelson wrote:
>
>
>             The real question we have regarding DT is the timing. We're
>             shipping
>             DT files on secondary storage (SATA/SD card), and want/need
>             something
>             local (i.e. env in SPI-NOR) to present a U/I if either no
>             storage
>             available or if something goes wrong.
>
>         ok, understood.
>
>             A secondary need/desire is to have something simple for
>             configuring
>             a new display. The process of tuning some of the parameters (esp
>             margins) can sometimes be iterative because the data sheets
>             aren't
>             always clear and clock options are often imprecise. Since this
>             iteration and configuration is often done by EEs in a lab who
>             don't have an easy way to recompile a DTS, our inclination is
>             to do something locally.
>
>         ok, I understand the point. Maybe it should be even more simple
>         for the
>         EEs if the would be such kind of special u-boot commands, able
>         to set
>         the timing and reload the framebuffer.
>
>         Can be a solution using the u-boot's fdt library enough ? With
>         "fdt get"
>         and "fdt set" it  is possible to read and modify a DT in memory, and
>         then the modified DT can be stored back - avoiding to compile
>         directly
>         the DTS.
>
>     Perhaps. We're still n00bs when it comes to DT, so we may have
>     to wait until we're further up the learning curve.
>
>     It also seems that a bound U-Boot+DT isn't really any better
>     than re-compiling U-Boot itself. If we need to flash everything,
>     then there's not much benefit of the change.
>
> If you use environment, where is that stored? Presumably you need to
> reflash in that case also?
>

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.

> 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

> In general FDT is pretty easy to set up - when you define
> CONFIG_OF_CONTROL you need to use u-boot-dtb.bin instead of u-boot.bin,
> but other than that it should work OK.
>

At the moment, I think somehow saving a fragment of DT information
in the environment and using it to "fix up" the FDT loaded from
boot medium is probably the right approach.

This is likely to be more verbose that the approach Anatolij
suggested ("videomode" environment variable), but has the benefit
of only needing one set of documentation.

Our previous work in this area (for i.MX51 and 53) had a command
'lcdpanel' which allowed for a process of <up-arrow>edit<enter>
to change and test a display setting:

	http://boundarydevices.com/u-boot-display-support-on-i-mx51/

But pasting a multi-line block isn't meaningfully more difficult.

Regards,


Eric