Hi Eric, On Sun, Jul 28, 2013 at 10:57 AM, Eric Nelson < eric.nel...@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.nel...@boundarydevices.com> >> <mailto:eric.nelson@**boundarydevices.com<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. 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
