From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerry Van Baren <gerald.vanbaren@ge.com>
Date: Tue, 27 Nov 2007 07:50:55 -0500
Subject: [U-Boot-Users] LIBFDT: bd_t and env embedding (was actual
 stxxtc board maintainer?)
In-Reply-To: <20071126222506.726D2248DB@gemini.denx.de>
References: <20071126222506.726D2248DB@gemini.denx.de>
Message-ID: <474C12AF.4000905@ge.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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