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

Pantelis Antoniou
2004-09-15T13:40:52Z

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