[U-Boot-Users] actual stxxtc board maintainer?

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Kumar Gala wrote:
> On Nov 26, 2007, at 12:00 PM, Dan Malek wrote:
> 
>> On Nov 26, 2007, at 8:58 AM, Kumar Gala wrote:
>>
>>> I see Dan Malek's name listed as the maintainer.  I'm wondering who  
>>> actually cares about this board?
>> Well, I do care.  :-)  I still use them.
>> Pantelis did most of the kernel + u-boot FDT work
>> with this board.  It was one of the first boards
>> that used FDT properly.
>>
>>> ask because this board is one of two that define:
>>> 	CONFIG_OF_HAS_BD_T
>>> 	CONFIG_OF_HAS_UBOOT_ENV
>>>
>>> However I'm under the believe that these options aren't really used  
>>> or need by this board (i know they aren't needed for the other).
>> I don't know what those mean any more.  There were
>> a couple of iterations of passing information with
>> nicely formatted records before the FDT turned into
>> what it is today.  They may have been used for that.
> 
> They were mechanisms to pass the full u-boot environment and bd_t as  
> nodes in the device tree.  I'm not aware of any in tree kernel support  
> that actually uses this information.
> 
> Does the stxxtc use it?
> 
> - k

Passing bd_t via the device tree is evil and should die (it probably is 
already dead, it just doesn't know it yet).  Anything in linux that is 
using bd_t variables through the device tree should be fixed: the values 
formerly passed through bd_t should already be available in existing 
properties, or else they should be made available.  That is the whole 
reason for FDT - to replace bd_t.

Passing the u-boot env via the device tree seems like a very useful 
thing to keep.  IMHO, this is a better way of accessing the u-boot 
variables than fw_printenv.  The problem with this concept currently is that
a) It isn't fully developed/adopted
b) The device tree passed to linux doesn't lend itself to writing (a RAM 
copy is passed, not a pointer to the flash-based original) so we don't 
have an equivalent to fw_setenv.

I would propose we keep the ability to embed the env variables in the 
blob, positioning ourselves to improving (a) and (b) going forward.

Best regards,
gvb