public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Pantelis Antoniou <panto@intracom.gr>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] Pass full u-boot environment to booting kernel
Date: Wed, 15 Sep 2004 16:40:52 +0300	[thread overview]
Message-ID: <41484664.20509@intracom.gr> (raw)
In-Reply-To: <20040915132425.29027C1430@atlas.denx.de>

Wolfgang Denk wrote:
> In message <Pine.LNX.4.61.0409151456120.3838@mag.sysgo.com> you wrote:
> 
>>This argument seems to create a chicken-and-egg problem. Why don't you 
>>let people step ahead and implement this? FWIW, Pantelis's arguments 
> 
> 
> I  also  disagree  with  the  solution  itself.  Passing  the  U-Boot
> environment  does  not  solve a couple of problems. IMHO bi_recs is a
> much better way to implement this. I'm just  waiting  that  there  is
> some  form  of  agreement what to do.
> 
> All of this is not exactly new. This discussion has been going on for
> more than two years now. Mark A. Greer made a nice proposal more than
> 2 years ago. See discussion on  the  linuxppc-embedded  mailing  list
> that  started  as  "EV-64260-BP  &  GT64260 bi_recs" around March 19,
> 2002. [Sorry, I'm aware that the lists and list  archives  are  down;
> please  feel  free  to  contact me if you want a copy of the relevant
> postings.]
> 
> Then there has been the OCP work by Matt Porter - etc. etc.
> 
> There is a lot of good existing proposals, and it makes IMHO not much
> sense to come up with yet another approach that does  not  solve  the
> old problems.
> 
> 
> Regarding the use of the U-Boot environment - here  is  some  of  the
> issues I see:
> 
> * there should be a way to pass information about "banks"  of  memory
>   (a  list  of  entries with physical start address, size, type [RAM,
>   ROM, flash, ...], ...)
> 
> * There should be a  list  of  network  interface  descriptions  (MAC
>   address, IP address etc., speed and duplex capabilities and current
>   settings etc.)

Right *now* there's nothing like that.

IMHO it's better to have something now that works adequately than wait
for the best solution which may be some years away.

There's a need and this thing covers it. I'd be more than happy to
use something better but nothing exists & nothing seems to be coming
along either.

> 
> And so on. bi_recs will allow  to  handle  such  lists  very  nicely.
> Trying  to  do  the  same in the U-Boot environment would blow up the
> environment and easily overflow it on most systems. Also parsing  and
> decoding  the  ASCII  representation  would  slow down the Linux boot
> process too much. Also  the  output  of  a  "printenv"  would  become
> unreadable, etc.

Obviously systems that don't need it, won't enable it.

And I don't think that searching the environment for a couple of variables
is going to be a perceptible slowdown.

> 
> The longer you think about this, the more reasons you will  find  why
> the  U-boot  environment  is  not  an  appropriate  way to solve this
> problem.

I'm open to suggestions.

> 
> Best regards,
> 
> Wolfgang Denk
> 

Regards

Pantelis

  reply	other threads:[~2004-09-15 13:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-14 10:25 [U-Boot-Users] [PATCH] Pass full u-boot environment to booting kernel Pantelis Antoniou
2004-09-14 11:47 ` Wolfgang Denk
2004-09-14 12:01   ` Pantelis Antoniou
2004-09-14 13:19     ` Wolfgang Denk
2004-09-14 13:26       ` Pantelis Antoniou
2004-09-14 15:28         ` Wolfgang Denk
2004-09-14 17:46       ` Eugene Surovegin
2004-09-14 20:37         ` Dan Malek
2004-09-15 13:05       ` Marius Groeger
2004-09-15 13:24         ` Wolfgang Denk
2004-09-15 13:40           ` Pantelis Antoniou [this message]
2004-09-15 14:54             ` Wolfgang Denk
2004-09-15 14:04           ` Marius Groeger
2004-09-15 15:00             ` Wolfgang Denk
2004-09-15 14:59           ` Robert Schwebel

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=41484664.20509@intracom.gr \
    --to=panto@intracom.gr \
    --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