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