[U-Boot-Users] (Try 2) Please pull branch fdt-cmd from u-boot-fdt.git

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Joakim Tjernlund wrote:
> On Tue, 2007-04-03 at 06:34 -0400, Jerry Van Baren wrote:
>> Joakim Tjernlund wrote:
>>> On Sat, 2007-03-31 at 13:43 -0400, Jerry Van Baren wrote:
>>>> Dear Wolfgang,
>>>>
>>>> Please pull from the "fdt-cmd" branch at
>>>>    git://cideas.us/pub/scm/u-boot/u-boot-fdt.git fdt-cmd
>>>> currently broken, someday fixed:
>>>>    git://denx.de/git/u-boot-fdt.git fdt-cmd
>>>>
>>>> I've resplit the patches and emailed them to the u-boot list.
>>>>
>>>> This change is only the starting point. :-) I've only done the
>>>> mpc8360/mpc8360emds board.  Some fairly small changes need to be done
>>>> to the other mpc8xxx family CPU and board subdirectories to allow them
>>>> to use the libfdt/fdt command.  To see what needs adapting, see:
>>>>   cpu/mpc83xx/cpu.c               |  102 +++++-
>>>>   board/mpc8360emds/pci.c         |   20 +
>>>>
>>>> Note that I've created a new CONFIG_OF_LIBFDT that is intended to
>>>> ultimately supplant CONFIG_OF_FLAT_TREE.  Use one or the other: new way
>>>> CONFIG_OF_LIBFDT or old way CONFIG_OF_FLAT_TREE.  Obviously, the only 
>>>> way to get the new fdt command is to use CONFIG_OF_LIBFDT.
>>> This is probably a little off but I am thinking about were to
>>> put my dtb on the flash and it occured to me that it could fit into the
>>> environment sector as the environment doesn't use the whole sector.
>>> But one can't just write it into that sector without take measures to
>>> preserve the environment.
>>> Is this a bad idea?
>>>
>>>  Jocke
>> That is an excellent idea and should be one of our goals: to better 
>> coordinate the dft and env variables.  As the penultimate goal, I 
>> believe we could move the env variables _into_ the dft and replace the 
>> get/set env routines with dft get/set routines.  I'm still thinking 
>> about this... env variables are used very early in power up (before RAM 
>> is initialized), but I haven't seen any reason that it /can't/ be done.
> 
> Good, I am not totally off then :)
> I think to start with one would just need an install dtb command that
> places the dtb at the end of the env. sector to allow either one
> to grow without trashing eachother. Also rendundant env needs to be
> handled by this new command.
> Secondly one needs someway of telling bootm where to find the dtb.
> 
> I have just started a board port here and there will be some time
> before I get to to the dtb part.
> 
>   Jocke

Hi Jocke,

* I've removed the fdt munging from bootm.  For the "fdt" flavor, you
     need to munge the blob explicitly (see "fdt chosen", "fdt env",
     "fdt bd_t").
* The "fdt address" subcommand tells u-boot where the blob is.
* The 3rd parameter to bootm is the blob address (unchanged).  We could
     use the address set by the "fdt address" command automatically, but
     I'm not wild about doing things automatically.

If and when we save blobs with/instead of the env...
* We will undoubtedly want redundancy and CRC protection.
* We will probably want to add a "merge" command that can take a u-boot
     blob (from the env area, for instance) and merge it with a loaded
     (kernel-related) blob.  This is easy to say, but again will take
     some thought because we will need to Do The Right Thing[tm] when a
     given property exists in both (need to establish which one wins).

gvb
P.S. s/dft/fdt/ in my previous post, s/sleep/caffine/ on me.  :-O