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

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

[Robert Winkler]

Hello all,

We're trying to figure out how best to get rid of static code like this:

http://git.denx.de/?p=u-boot.git;a=blob;f=board/boundary/nitrogen6x/nitrogen6x.c;h=8f0f9b8de2e8e77fcbf477728ea063a213941dd0;hb=HEAD#l526

and turn it into run time data.

Our idea is to use an environment variable so adding support for new
screens and iterating on minor settings is quick and easy and then we can
remove the static arrays like the one above and in wandboard.c and other
places.


One way to do this is to create a data structure that can subsume the
functionalities of of display_info_t and the various structures in lcd.h
and elsewhere that can be used throughout U-Boot both with CONFIG_LCD and
CONFIG_CFB_CONSOLE.  Combined with the EDID functionality already in U-Boot
this would allow code to easily select the "best" display supported by the
monitor or closest to what the user wanted (given in the environment
variable).  This data structure would then be passed to Linux on boot up.


I realize that there's already the FDT and CONFIG_OF_CONTROL functionality
and device trees sort of cover the passing to Linux part so maybe before
handing it off, converting the relevant data into a device tree that Linux
can already use/parse would work.

Is anyone working on something like this?  Am I missing something that's
already in place to accomplish this?


Thanks,

Robert Winkler

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

[Anatolij Gustschin]

Hello Robert,

On Thu, 25 Jul 2013 11:21:10 -0700
Robert Winkler <robert.winkler@boundarydevices.com> wrote:

> Hello all,
> 
> We're trying to figure out how best to get rid of static code like this:
> 
> http://git.denx.de/?p=u-boot.git;a=blob;f=board/boundary/nitrogen6x/nitrogen6x.c;h=8f0f9b8de2e8e77fcbf477728ea063a213941dd0;hb=HEAD#l526
> 
> and turn it into run time data.
> 
> Our idea is to use an environment variable so adding support for new
> screens and iterating on minor settings is quick and easy and then we can
> remove the static arrays like the one above and in wandboard.c and other
> places.

We have some code and users to define timing parameters in an environment
variable "videomode". video_get_params() is used to read the parameters
into a structure "struct ctfb_res_modes".

> One way to do this is to create a data structure that can subsume the
> functionalities of of display_info_t and the various structures in lcd.h
> and elsewhere that can be used throughout U-Boot both with CONFIG_LCD and
> CONFIG_CFB_CONSOLE.  Combined with the EDID functionality already in U-Boot
> this would allow code to easily select the "best" display supported by the
> monitor or closest to what the user wanted (given in the environment
> variable).  This data structure would then be passed to Linux on boot up.
>
> I realize that there's already the FDT and CONFIG_OF_CONTROL functionality
> and device trees sort of cover the passing to Linux part so maybe before
> handing it off, converting the relevant data into a device tree that Linux
> can already use/parse would work.

Devicetree bindings for describing display timings info exist in recent
Linux kernel versions (since v3.9 I think) and are documented under
Documentation/devicetree/bindings/video/display-timing.txt. In Linux
there are also DT helpers to parse display timings nodes and read the
timing values into fb_videomode structure (of_get_display_timings,
of_get_fb_videomode). Code for adding such display timings nodes to
the device tree under U-Boot doesn't exist yet.

> Is anyone working on something like this?  Am I missing something that's
> already in place to accomplish this?

Maybe you can use "videomode" Variable and video_get_params().

Thanks,

Anatolij

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

[Stefano Babic]

Hi Robert, Anatolji,

On 26/07/2013 09:50, Anatolij Gustschin wrote:

>>
>> I realize that there's already the FDT and CONFIG_OF_CONTROL functionality
>> and device trees sort of cover the passing to Linux part so maybe before
>> handing it off, converting the relevant data into a device tree that Linux
>> can already use/parse would work.
> 
> Devicetree bindings for describing display timings info exist in recent
> Linux kernel versions (since v3.9 I think) and are documented under
> Documentation/devicetree/bindings/video/display-timing.txt. In Linux
> there are also DT helpers to parse display timings nodes and read the
> timing values into fb_videomode structure (of_get_display_timings,
> of_get_fb_videomode). Code for adding such display timings nodes to
> the device tree under U-Boot doesn't exist yet.

IMHO adopting DT looks very interesting, as it can really simplify
sharing configuration between u-boot and kernel. On i.MX6 we have not
yet started to use DT to configure u-boot as it is already done on other
SOCs (Tegra), but it seems to me the right way to do.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

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

[Eric Nelson]

Thanks Anatolij,

On 07/26/2013 12:50 AM, Anatolij Gustschin wrote:
> Hello Robert,
>
> On Thu, 25 Jul 2013 11:21:10 -0700
> Robert Winkler <robert.winkler@boundarydevices.com> wrote:
>
>> Hello all,
>>
>> We're trying to figure out how best to get rid of static code like this:
>>
>> http://git.denx.de/?p=u-boot.git;a=blob;f=board/boundary/nitrogen6x/nitrogen6x.c;h=8f0f9b8de2e8e77fcbf477728ea063a213941dd0;hb=HEAD#l526
>>
>> and turn it into run time data.
>>
>> Our idea is to use an environment variable so adding support for new
>> screens and iterating on minor settings is quick and easy and then we can
>> remove the static arrays like the one above and in wandboard.c and other
>> places.
>
> We have some code and users to define timing parameters in an environment
> variable "videomode". video_get_params() is used to read the parameters
> into a structure "struct ctfb_res_modes".
>

:)

When searching for the proper way to do things, we found two data
structures in wide use:
	fb_videomode
	vidinfo

We didn't find ctfb_res_modes...

>> One way to do this is to create a data structure that can subsume the
>> functionalities of of display_info_t and the various structures in lcd.h
>> and elsewhere that can be used throughout U-Boot both with CONFIG_LCD and
>> CONFIG_CFB_CONSOLE.  Combined with the EDID functionality already in U-Boot
>> this would allow code to easily select the "best" display supported by the
>> monitor or closest to what the user wanted (given in the environment
>> variable).  This data structure would then be passed to Linux on boot up.
>>
>> I realize that there's already the FDT and CONFIG_OF_CONTROL functionality
>> and device trees sort of cover the passing to Linux part so maybe before
>> handing it off, converting the relevant data into a device tree that Linux
>> can already use/parse would work.
>
> Devicetree bindings for describing display timings info exist in recent
> Linux kernel versions (since v3.9 I think) and are documented under
> Documentation/devicetree/bindings/video/display-timing.txt. In Linux
> there are also DT helpers to parse display timings nodes and read the
> timing values into fb_videomode structure (of_get_display_timings,
> of_get_fb_videomode). Code for adding such display timings nodes to
> the device tree under U-Boot doesn't exist yet.
>
>> Is anyone working on something like this?  Am I missing something that's
>> already in place to accomplish this?
>
> Maybe you can use "videomode" Variable and video_get_params().

That would handle most things, though there are some bits missing.

In particular, these things aren't expressed in either fb_videomode
or ctfb_res_modes:

	- which display connection? Our SABRE Lite and Nitrogen6x
	boards have three display connections (HDMI, LVDS, RGB)

	- details of the connection. For instance, the LVDS output
	on our boards can send data using either the SPWG or JEIDA
	standards, and the RGB connection can be configured for
	either 16, 18, or 24 bit displays

It seems that at least two-levels of data structure are needed:
one to represent the board-level options for display, and another
for the panel-specific resolution information.

That lack of separation seems to be behind the big set
of #ifdefs around the declaration of vidinfo in lcd.h.

Regards,


Eric

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

[Eric Nelson]

Hi Stefano,

On 07/26/2013 01:43 AM, Stefano Babic wrote:
> Hi Robert, Anatolji,
>
> On 26/07/2013 09:50, Anatolij Gustschin wrote:
>
>>>
>>> I realize that there's already the FDT and CONFIG_OF_CONTROL functionality
>>> and device trees sort of cover the passing to Linux part so maybe before
>>> handing it off, converting the relevant data into a device tree that Linux
>>> can already use/parse would work.
>>
>> Devicetree bindings for describing display timings info exist in recent
>> Linux kernel versions (since v3.9 I think) and are documented under
>> Documentation/devicetree/bindings/video/display-timing.txt. In Linux
>> there are also DT helpers to parse display timings nodes and read the
>> timing values into fb_videomode structure (of_get_display_timings,
>> of_get_fb_videomode). Code for adding such display timings nodes to
>> the device tree under U-Boot doesn't exist yet.
>
> IMHO adopting DT looks very interesting, as it can really simplify
> sharing configuration between u-boot and kernel. On i.MX6 we have not
> yet started to use DT to configure u-boot as it is already done on other
> SOCs (Tegra), but it seems to me the right way to do.
>

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.

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.

Is Tegra somehow using DT to configure U-Boot display?
I'm not finding the code.

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.

Please advise,


Eric

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

[Stefano Babic]

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.

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

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

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

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

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

[Stephen Warren]

On 07/26/2013 08:42 AM, Stefano Babic wrote:
> 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.

For Tegra (and I assume the similar Exynos support), the DTB that's used
by U-Boot is considered part of the U-Boot binary, so whatever loads
that into RAM also automatically picks up the DTB, so there's no need to
do any kind of storage access to retrieve it

Of course, the U-Boot code apparently supports other methods, such as
hard-coding a memory-mapped address etc.; take a lok at the DT-related
config options.

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

Yes, that's working fine.

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

[Eric Nelson]

Thanks Stephen,

On 07/26/2013 07:49 AM, Stephen Warren wrote:
> On 07/26/2013 08:42 AM, Stefano Babic wrote:
>> 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.
>
> For Tegra (and I assume the similar Exynos support), the DTB that's used
> by U-Boot is considered part of the U-Boot binary, so whatever loads
> that into RAM also automatically picks up the DTB, so there's no need to
> do any kind of storage access to retrieve it
>

Interesting... and the fdtdec_X() routines give you a mini database
you can query for the bits of interest, which can handle the
interface-specific bits pretty nicely.

> Of course, the U-Boot code apparently supports other methods, such as
> hard-coding a memory-mapped address etc.; take a lok at the DT-related
> config options.
>

Now if only there were a way to represent some DT data in an
environment variable...

I mean, there is, but somehow this just seems wrong:

	U-Boot > setenv mypanel '
	> clock = <54030000>;
	> xres = <1024>;
	> yres = <600>;
	> ...
	> '

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

[Eric Nelson]

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.

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

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

[Troy Kisky]

On 7/26/2013 5:42 PM, Eric Nelson wrote:
> 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 just booted 3 displays on 3.5.7 without a video= on the command line.
So, device tree can do what the command line can.

Troy

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

[Simon Glass]

Hi Eric,

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

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

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

[Eric Nelson]

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

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

[Simon Glass]

Hi Eric,

On Sun, Jul 28, 2013 at 10:57 AM, Eric Nelson <
eric.nelson@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@boundarydevices.com>
>> <mailto:eric.nelson@**boundarydevices.com<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.


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

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

[Eric Nelson]

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

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

[Simon Glass]

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

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