[U-Boot] [RFC] Remove static display data
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/nitrogen...
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
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/nitrogen...
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
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
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
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
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.
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>; > ... > '
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
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
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
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
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@boundarydevices.**com eric.nelson@boundarydevices.com <mailto:eric.nelson@**boundarydevices.comeric.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
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 FDTWe 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
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 supportWindows 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 FDTWe 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
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/nitrogen...
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
participants (7)
-
Anatolij Gustschin -
Eric Nelson -
Robert Winkler -
Simon Glass -
Stefano Babic -
Stephen Warren -
Troy Kisky