From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Re: FT u-boot shim
Date: Thu, 27 Apr 2006 16:40:05 -0400 [thread overview]
Message-ID: <44512C25.2080105@smiths-aerospace.com> (raw)
In-Reply-To: <20060427194316.CBFBC353A57@atlas.denx.de>
Wolfgang Denk wrote:
> In message <44511C88.1010107@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.
next prev parent reply other threads:[~2006-04-27 20:40 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060426191957.14C4F353DAC@atlas.denx.de>
2006-04-27 18:18 ` [U-Boot-Users] Re: FT u-boot shim Kumar Gala
2006-04-27 19:05 ` Wolfgang Denk
2006-04-27 19:20 ` Kumar Gala
2006-04-27 19:33 ` Jerry Van Baren
2006-04-27 19:42 ` Kumar Gala
2006-04-27 19:43 ` Wolfgang Denk
2006-04-27 20:40 ` Jerry Van Baren [this message]
2006-04-27 21:25 ` Pantelis Antoniou
2006-04-27 21:45 ` Wolfgang Denk
2006-04-27 19:40 ` Wolfgang Denk
2006-04-27 19:46 ` Kumar Gala
2006-04-27 19:59 ` Kumar Gala
2006-04-27 21:36 ` Wolfgang Denk
2006-04-27 21:55 ` Tolunay Orkun
2006-04-27 22:12 ` Wolfgang Denk
2006-04-27 22:28 ` Pantelis Antoniou
2006-04-27 22:55 ` Wolfgang Denk
2006-04-28 7:34 ` Pantelis Antoniou
2006-04-28 7:43 ` Wolfgang Denk
2006-04-28 8:03 ` Pantelis Antoniou
2006-04-28 9:37 ` ???
2006-04-28 9:51 ` Wolfgang Denk
2006-04-28 16:10 ` Tolunay Orkun
2006-04-28 16:36 ` [U-Boot-Users] Re: FT u-boot shim - using ramdisk? Roger Larsson
2006-04-28 19:30 ` Kumar Gala
2006-04-28 19:34 ` Wolfgang Denk
2006-04-27 19:30 [U-Boot-Users] RE: FT u-boot shim Rune Torgersen
2006-04-27 19:40 ` [U-Boot-Users] " Kumar Gala
2006-04-27 19:45 ` Wolfgang Denk
2006-04-27 19:54 ` Kumar Gala
2006-04-27 21:34 ` Wolfgang Denk
-- strict thread matches above, loose matches on Subject: below --
2006-04-28 16:25 Rune Torgersen
2006-04-28 19:28 ` Wolfgang Denk
2006-04-28 19:50 ` Pantelis Antoniou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44512C25.2080105@smiths-aerospace.com \
--to=gerald.vanbaren@smiths-aerospace.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox