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.nel...@boundarydevices.com
<mailto:eric.nel...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
