[U-Boot-Users] LIBFDT: bd_t and env embedding (was actual stxxtc board maintainer?)
Jerry Van Baren
gerald.vanbaren at ge.com
Tue Nov 27 13:50:55 CET 2007
Wolfgang Denk wrote:
> In message <474B14C2.8030708 at 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
More information about the U-Boot
mailing list