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