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

[Pantelis Antoniou]

Wolfgang Denk wrote:
> 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.)

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