All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.