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

[Simon Glass]

Hi Eric,

On Sun, Jul 28, 2013 at 10:57 AM, Eric Nelson <
eric.nelson at boundarydevices.com> wrote:

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


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.


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


>
>
>  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/<http://boundarydevices.com/u-boot-display-support-on-i-mx51/>
>
> But pasting a multi-line block isn't meaningfully more difficult.
>
> Regards,
>
>
> Eric
>

Regards,
Simon