Pass full u-boot environment to booting kernel
PATCH 1/1 Pass full u-boot environment to booting kernel
Hi
The following patch allows the passing of the full u-boot environment to the booting running kernel.
What it does after that is a matter of discussion currently.
In the following days I'll also post patches for the kernel and busybox showing what can be acheived.
Regards
Pantelis
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: passenv.changelog
Url: http://lists.denx.de/pipermail/u-boot/attachments/20040914/b451a962/attachment.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: passenv.diffstat
Url: http://lists.denx.de/pipermail/u-boot/attachments/20040914/b451a962/attachment-0001.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: passenv.patch
Type: text/x-patch
Size: 3658 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20040914/b451a962/attachment.bin
PATCH 1/1 Pass full u-boot environment to booting kernel
Quoted 5 lines · In message <[email protected]> you wrote:
The following patch allows the passing of the full u-boot environment to the booting running kernel.
What it does after that is a matter of discussion currently.
Which discussion are you referring to? I haven't seen any related message yet.
Quoted 2 lines
In the following days I'll also post patches for the kernel and busybox showing what can be acheived.
Please hold on for a moment.
I'm afraid I have to tell you that I don't think this makes sense at all.
There are several reasons for me to tend to reject this patch:
* The Linux kernel's command line is limited in size. You cannot pass arbitrary amounts of data to the kernel this way.
* If you want to make the U-Boot environment accessable to the kernel, there are other (better?) ways like making it available by the kernel directory (reading directly through the MTD layer for flash, or from I2C for EEPROM, etc.).
* The U-Boot environment usually contains LOTS of definitions which are definitely useless in the Linux kernel, so why pass random data which will never be needed anyway?
Best regards,
Wolfgang Denk
Signature · 7 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de You speak of courage. Obviously you do not know the difference bet- ween courage and foolhardiness. Always it is the brave ones who die, the soldiers. -- Kor, the Klingon Commander, "Errand of Mercy", stardate 3201.7
PATCH 1/1 Pass full u-boot environment to booting kernel
Quoted 11 lines · Wolfgang Denk
Quoted 4 lines · In message <[email protected]> you wrote:
The following patch allows the passing of the full u-boot environment to the booting running kernel.
What it does after that is a matter of discussion currently.
Which discussion are you referring to? I haven't seen any related message yet.
It's a discussion related to the kernel. Its mainly private email exchanges.
The consensus is that there is no consensus for anything but the fact that something like this is needed.
The other solution discussed is bi_recs.
Quoted 7 lines
Quoted 3 lines
In the following days I'll also post patches for the kernel and busybox showing what can be acheived.
Please hold on for a moment.
Quoted 7 lines
I'm afraid I have to tell you that I don't think this makes sense at all.
There are several reasons for me to tend to reject this patch:
* The Linux kernel's command line is limited in size. You cannot pass arbitrary amounts of data to the kernel this way.
If you take a look at the patch you'll see that the environment is not passed in the command line.
Merely a memory structure in a non-overwrittable area is created and the (physical) address of it is passed to the kernel.
The only thing passed to the kernel is "u-boot-env=007a3140".
There are no adverse effects if the kernel image does not understand the option.
And finally this functionality is controlled by a single define. If you don't need it just don't define it.
Quoted 5 lines
* If you want to make the U-Boot environment accessable to the kernel, there are other (better?) ways like making it available by the kernel directory (reading directly through the MTD layer for flash, or from I2C for EEPROM, etc.).
No there not.
The point is not to pass the stored environment settings, but the ones active at the moment of booting.
For example if the network settings are obtained by means of DHCP there are not generally stored in the non-volatile environment.
Quoted 4 lines
* The U-Boot environment usually contains LOTS of definitions which are definitely useless in the Linux kernel, so why pass random data which will never be needed anyway?
It's not just for the kernel. The boot variables are invaluable for your applications too.
Quoted 5 lines
Best regards,
Wolfgang Denk
Regards
Pantelis
PATCH 1/1 Pass full u-boot environment to booting kernel
Quoted 3 lines · In message <[email protected]> you wrote:
It's a discussion related to the kernel. Its mainly private email exchanges.
I really like this new trend in Free Software development :-(
The interesting public mailing lists (linuxppc) get shut down, and discussions about future kernel developments take place on IRC or "private email exchanges" only.
If you don't happen do be chosen for such elitist circles you cannot participate in kernel development any more.
This is not my idea of how things should be done.
Quoted 4 lines
The consensus is that there is no consensus for anything but the fact that something like this is needed.
The other solution discussed is
bi_recs.
I will not comment on things I have no chance to get an opinion about.
Quoted 5 lines
If you take a look at the patch you'll see that the environment is not passed in the command line.
Merely a memory structure in a non-overwrittable area is created and the (physical) address of it is passed to the kernel.
There is no kernel interface for such stuff in existing Linux kernels (at least as far as they are accessable by mere mortals). There is not even a definition of "non-overwrittable area".
As long as there is no agreement how the Linux kernel will handle these issues (and with "Linux kernel" I mean what you get at kernel.org, and what works at least on ARM, MIPS and PowerPC) I do not want to add this to U-Boot.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Systems programmers are the high priests of a low cult.
-- R.S. BartonPATCH 1/1 Pass full u-boot environment to booting kernel
Quoted 8 lines · Wolfgang Denk
Quoted 2 lines · In message <[email protected]> you wrote:
It's a discussion related to the kernel. Its mainly private email exchanges.
I really like this new trend in Free Software development :-(
Quoted 9 lines
The interesting public mailing lists (linuxppc) get shut down, and discussions about future kernel developments take place on IRC or "private email exchanges" only.
If you don't happen do be chosen for such elitist circles you cannot participate in kernel development any more.
This is not my idea of how things should be done.
Nothing is closed. You are welcome to discuss this online @ #mklinux.
It's just that for some matters the latency of email is too much.
And if you've noticed the lists were out of commission for about a week and a half.
Quoted 9 lines
Quoted 6 lines
The consensus is that there is no consensus for anything but the fact that something like this is needed.
The other solution discussed is
bi_recs.I will not comment on things I have no chance to get an opinion about.
Again please make your case online.
Quoted 14 lines
Quoted 7 lines
If you take a look at the patch you'll see that the environment is not passed in the command line.
Merely a memory structure in a non-overwrittable area is created and the (physical) address of it is passed to the kernel.
There is no kernel interface for such stuff in existing Linux kernels (at least as far as they are accessable by mere mortals). There is not even a definition of "non-overwrittable area".
Quoted 4 lines
As long as there is no agreement how the Linux kernel will handle these issues (and with "Linux kernel" I mean what you get at kernel.org, and what works at least on ARM, MIPS and PowerPC) I do not want to add this to U-Boot.
Understood.
Quoted 5 lines
Best regards,
Wolfgang Denk
The simple matter is that the community is by definition disorganized.
There is no great designer, but authority figure to declare this or that by fiat. Just a bunch of poor slobs trying to reach a censunsus.
I'm not happy about a number of things but I'll be damned if I sit in my chair and pout about them.
If you want to affect the course of development you must get involved. This is specially important now since the 2.6 kernel is just getting to work on some important embedded ppc platforms.
It is shame for all your fine contributions to be discarded, but you must get the word out about them.
Regards
Pantelis
PATCH 1/1 Pass full u-boot environment to booting kernel
Quoted 2 lines · In message <[email protected]> you wrote:
Nothing is closed. You are welcome to discuss this online @ #mklinux.
I see. Where can I find a log of previous discussions so that I don't have to be on IRC for 24:7 or start asking stuff that has already been discussed?
Quoted 1 line
It's just that for some matters the latency of email is too much.
This is nonsense.
Quoted 2 lines
And if you've noticed the lists were out of commission for about a week and a half.
Yes, this is waht I complained about, too.
Quoted 3 lines
Quoted 1 line
I will not comment on things I have no chance to get an opinion about.
Again please make your case online.
How can I? Where can I read the previous discussion?
Quoted 1 line
The simple matter is that the community is by definition disorganized.
No. There has been a lot of experience with working in a not formally organized group. Usenet is much, much older even. There has been a long tradition of newsgroups and mailing lists, which both have their special benefits, andvantages and disadvantages.
IRC may be fine for making an appointment for dinner, or guiding somebody through a debug session or the like. It is not appropriate as the SINGLE channel for kernel development.
Quoted 2 lines
It is shame for all your fine contributions to be discarded, but you must get the word out about them.
I will be happy to do that. In a medium where others can find the information, too. Even if they don;t happen to be online the very same moment.
[But all this is off topic here.]
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de A person with one watch knows what time it is; a person with two watches is never sure. Proverb
PATCH 1/1 Pass full u-boot environment to booting kernel
In reply to Wolfgang DenkQuoted 3 lines · Wolfgang Denk
The interesting public mailing lists (linuxppc) get shut down, and discussions about future kernel developments take place on IRC or "private email exchanges" only.
PATCH 1/1 Pass full u-boot environment to booting kernel
Quoted 1 line · Eugene Surovegin
Quoted 1 line
From IRC "elitist circle":
You folks just need to get used to using the penguinppc.org web site for information. It's all been documented there for everyone to see. I'm on IRC lots of the time, and had to go to the web site to find the info.
Thanks.
-- Dan
PATCH 1/1 Pass full u-boot environment to booting kernel
In reply to Wolfgang DenkHello All,
let's try to get back to the original post.
Quoted 4 lines · Wolfgang Denk
As long as there is no agreement how the Linux kernel will handle these issues (and with "Linux kernel" I mean what you get at kernel.org, and what works at least on ARM, MIPS and PowerPC) I do not want to add this to U-Boot.
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 sound very reasonable to me. If there's a kernel patch needed to make use of this feature, so be it. I also need a kernel patch to use U-Boot with the MBX and maybe a number of other platforms. You shouldn't reject things on the mere grounds that you were not involved creating them. And if all fails -- the patch complies U-Boot's submission rules, you can turn it off, and most likely easily remove it in the future, should someone invent something smarter.
Regards,
Marius
Signature · 4 lines
Marius Groeger <[email protected]> SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com
PATCH 1/1 Pass full u-boot environment to booting kernel
Quoted 3 lines · In message <[email protected]> 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
Signature · 3 lines
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.
PATCH 1/1 Pass full u-boot environment to booting kernel
Quoted 29 lines · Wolfgang Denk
Quoted 2 lines · In message <[email protected]> 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_recsis 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:
Quoted 7 lines
* 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.
Quoted 7 lines
And so on.
bi_recswill 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.
Quoted 4 lines
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.
Quoted 5 lines
Best regards,
Wolfgang Denk
Regards
Pantelis
PATCH 1/1 Pass full u-boot environment to booting kernel
Quoted 3 lines · In message <[email protected]> you wrote:
IMHO it's better to have something now that works adequately than wait for the best solution which may be some years away.
OK. But then let's implement something that at least has a chance of being accepted widely, and that actually solves the problems instead of creating new ones.
What's your opinoin about implementing Mark A. Greer's bi_recs proposal instead?
Quoted 1 line
There's a need and this thing covers it. I'd be more than happy to
No. It causes additional problems that are not easy to solve.
Quoted 7 lines
Quoted 5 lines
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.
If your proposal works as intended, it may become the satndard interface to pass information to the kernel, so it should work on all systems. Also, maybe I _need_ this on a system with just a 2 kB EEPROM. What will I do then? In such a situation the environment space is usually tight already now. And remember that the RAM copy of the environment is not bigger than the persistent copy (and this is intentionally, because otherwise you run into trouble when trying to "saveenv").
Quoted 2 lines
And I don't think that searching the environment for a couple of variables is going to be a perceptible slowdown.
No matter how much it is, it is wasted effort. There are systems where each millisecond is precious.
Quoted 1 line
I'm open to suggestions.
See above. What about Mark's proposal? And what shall we do with the OCP stuff?
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de "If God had wanted us to use the metric system, Jesus would have had 10 apostles."
PATCH 1/1 Pass full u-boot environment to booting kernel
In reply to Wolfgang DenkQuoted 4 lines · Wolfgang Denk
I also disagree with the solution itself. Passing the U-Boot environment does not solve a couple of problems. IMHO
bi_recsis a much better way to implement this. I'm just waiting that there is some form of agreement what to do.
I must have misunderstood you: didn't you want a solution that is available on PPC, ARM and MIPS? It is not at all likely that the ARM folks give up their ATAGs in favour of PPCs bi_recs because of a boot-loader, let alone one they never wanted in the first place. Even given that ATAG's and bi_recs are essentially the same, it will hardly allow U-Boots implementation nor the kernel API to have much common code.
PATCH 1/1 Pass full u-boot environment to booting kernel
Quoted 3 lines · In message <[email protected]> you wrote:
I must have misunderstood you: didn't you want a solution that is available on PPC, ARM and MIPS? It is not at all likely that the ARM
Yes.
Quoted 1 line
folks give up their ATAGs in favour of PPCs
bi_recsbecause of a
So this discussion should probably take place on lkml instead? ;-)
Quoted 4 lines
boot-loader, let alone one they never wanted in the first place. Even given that ATAG's and
bi_recsare essentially the same, it will hardly allow U-Boots implementation nor the kernel API to have much common code.
You got an important point here: ATAG's and bi_recs _are_ essentially the same, except for the name. I have no preference for either of these names, and I will not complain the the PowerPC and MIPS soultions use something which is called ATAG, too.
Quoted 2 lines
Quoted 1 line
From that point of view, Pantelis's proposal looks much more generic,
and people are willing to develop it now.
I see what it can do, but I see also all the problems that are involved. If we implement something new, then please let's do it
right: let's actually try to learn from all the previous discussions and implementations and create something which does not introduce new known problems, and which is not restricted to a specific boot loader.
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de "Engineering without management is art." - Jeff Johnson
PATCH 1/1 Pass full u-boot environment to booting kernel
In reply to Wolfgang DenkQuoted 5 lines · Wolfgang Denk
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.
Any reason why this is not being discussed on LKML? The problem is surely not architecture specific (ok - probably "every architecture but x86).
Robert
Signature · 5 lines
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstra?e 12, 31137 Hildesheim, Germany
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4