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