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

[Simon Glass]

Hi Eric,

On Fri, Jul 26, 2013 at 6:42 PM, Eric Nelson <
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?

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>

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.


>
>
>>> Is Tegra somehow using DT to configure U-Boot display?
>>> I'm not finding the code.
>>>
>>
>> ./board/compal/dts/tegra20-**paz00.dts seems doing that, but I have no
>> experience with it ;(
>>
>> My thoughts are more related by comparing what the kernel does and how
>> the timing is configured. There are several examples (I am seeing the
>> imx23-dts, but it is not the only one) where the complete timing for a
>> panel is done inside the DT.
>>
>>
> Again, we're not completely ready to comment, but it seems that
> using the phrase "what the kernel does" is going to be a moving
> target for a while. At least for i.MX.
>
> AFAIK, the 3.5.7 kernels from Freescale will still require kernel
> command lines for display configuration, so we may not have
> a firm target.
>
> I'm CC'ing Fabio and Jason for their 2c.
>
>
>  As you have already checked, using a U-Boot variable has some
>> limitations, because it does not contain all parameters that are needed.
>> And I think it could be quite difficult to get it general for all SOCs
>> because some SOCs need some specialties (VRAM for OMAP could be an
>> example).
>>
>>
> Anatolij's variable parser could be used and extended/wrapped
> to do the trick. I'm just not quite sure it's the right thing.
>
>
>  No matter how we end up doing this, passing U-Boot's display
>>> setup to the kernel via DT is the **right thing**, so that
>>> there aren't two bits to maintain.
>>>
>>
>> Yes, I think we do not need to discuss how to pass to the kernel - but I
>> am checking if it is a suitable way to configure the u-boot display,too.
>> Anyway, I agree that using a U-Boot variable is much more simple to
>> implement..
>>
>>
> Okay. We'll keep thinking about this, but it will likely go toward
> the back of our 'to-do' list.
>
>  Best regards,
>> Stefano
>>
>>
> Regards,
>
>
> Eric
>


Regards,
Simon