[U-Boot-Users] LIBFDT: bd_t and env embedding (was actual stxxtc board maintainer?)

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

Wolfgang Denk wrote:
> In message <474B14C2.8030708@ge.com> you wrote:
>> Passing bd_t via the device tree is evil and should die (it probably is 
> 
> Agreed.
> 
>> 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 
> 
> Ummm ... what would it be good for?
> 
>> variables than fw_printenv.  The problem with this concept currently is that
> 
> In which way is that better? One significant drawback is that such
> access would necessarily be read-only, while with fw_setenv you can
> modify the environment.
> 
> But really, why would an additional copy be better? TO me it seems
> just a waste of CPU cycles and memory footprint.
> 
>> I would propose we keep the ability to embed the env variables in the 
>> blob, positioning ourselves to improving (a) and (b) going forward.
> 
> I fail to see any benefit from doing that...
> 
> Best regards,
> Wolfgang Denk

Hi Wolfgang,

I'm just having a hard time letting go of my dream of FDT world 
domination, starting with using a blob to hold the u-boot env variables. :-)

If we ever /do/ have an option to store env variables in a blob, we 
won't need to have (the current) extra code to jam the non-FDT env 
variables into the blob anyway.  ;-)

I don't have any problem removing both the bd_t *and* the env embedding 
"features" since the former is evil and the latter is unused.

Best regards,
gvb