[U-Boot-Users] [PATCH] Pass full u-boot environment to booting kernel

[Wolfgang Denk]

In message <Pine.LNX.4.61.0409151456120.3838 at 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.)

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.

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.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Madness takes its toll. Please have exact change.