[U-Boot-Users] Re: FT u-boot shim

Jerry Van Baren gerald.vanbaren at smiths-aerospace.com
Fri Apr 28 06:40:05 EST 2006


Wolfgang Denk wrote:
> In message <44511C88.1010107 at smiths-aerospace.com> you wrote:
>> A thought that keeps recurring (but I've suppressed because I don't have 
>> time to play...) is that it would be Really Cool[tm] to store the u-boot 
>> env variables in a flat tree and then pass the env/tree to linux.  It 
> 
> If somebody wants to read the environment variables, you  don't  need
> to create a flat tree from it.

Understood.  That is why it is Really Cool[tm] rather than Really 
Useful[tm] ;-)

> Also, it doesn't solve the original problem as most of  the  informa-
> tion  you  need to pass is NOT part of the environment (and shall not
> become such a part).
> 
> Best regards,
> Wolfgang Denk

I agree and disagree with the parenthetical part of your statement. 
Agree because it _wouldn't_ be a part of u-boot (technically it would be 
if someone put it in their default env for their specific board, but why 
would denx.de care?).

Disagree because, while u-boot needs/uses some env variables, 
engineers/companies/end users are free to add variables and, I dare say, 
most do.  If a given board needs to pass certain non u-boot parameters 
to linux, it would simply add that to its env (which already happens).

I'm not sure you (Wolfgang and Kumar) are following my thought fully (or 
my ignorance is showing to everybody but me).  The thought is to change 
the native format of the u-boot environment storage from the 
key-string/value-string pairs to the flat tree (OpenFirmware) format 
which still supports the same key-string/value-string capability (but 
can do more than that).

The advantage, as I see it, is that it would be unifying and thus easier 
to maintain the common variables (call it the GRand Unifying Flat Tree 
(GRAFT) ;-).  One language (flat tree), no shims, equivalent key/value 
utility (but a different underlying storage format), no visible 
difference for the users (but potentially an upgrade challenge for 
existing boards and env variables).

The disadvantage is that it would be disruptive to u-boot and may cause 
some bloating and discomfort.

gvb
(the naive)

P.S. For the non-USA readers: "may cause some bloating and discomfort" 
is a standard disclaimer on medicines advertised on TV over here.



More information about the Linuxppc-dev mailing list