From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pantelis Antoniou Date: Wed, 15 Sep 2004 16:40:52 +0300 Subject: [U-Boot-Users] [PATCH] Pass full u-boot environment to booting kernel In-Reply-To: <20040915132425.29027C1430@atlas.denx.de> References: <20040915132425.29027C1430@atlas.denx.de> Message-ID: <41484664.20509@intracom.gr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wolfgang Denk wrote: > In message 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