[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