[U-Boot-Users] [PATCH] 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
* Patch by Pantelis Antoniou, 14 Sep 2004: Pass full current environment to linux.
README | 9 +++++++ common/cmd_bootm.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 66 insertions(+), 5 deletions(-)
In message 4146C728.7010006@intracom.gr 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.
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
Wolfgang Denk wrote:
In message 4146C728.7010006@intracom.gr 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.
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 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.
- 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.
- 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.
Best regards,
Wolfgang Denk
Regards
Pantelis
In message 4146DDA4.5070009@intracom.gr 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.
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.
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
Wolfgang Denk wrote:
In message 4146DDA4.5070009@intracom.gr 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.
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.
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.
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.
Understood.
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
In message 4146F191.3000800@intracom.gr 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?
It's just that for some matters the latency of email is too much.
This is nonsense.
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.
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?
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.
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
On Tue, Sep 14, 2004 at 03:19:53PM +0200, Wolfgang Denk wrote:
The interesting public mailing lists (linuxppc) get shut down, and discussions about future kernel developments take place on IRC or "private email exchanges" only.
From IRC "elitist circle":
linuxppc-dev has moved http://ozlabs.org/mailman/listinfo/linuxppc-dev
-- Eugene
On Sep 14, 2004, at 1:46 PM, Eugene Surovegin wrote:
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
Hello All,
let's try to get back to the original post.
On Tue, 14 Sep 2004, Wolfgang Denk wrote:
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
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.)
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
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
In message 41484664.20509@intracom.gr 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?
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.
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").
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.
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
On Wed, 15 Sep 2004, Wolfgang Denk wrote:
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.
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.
From that point of view, Pantelis's proposal looks much more generic,
and people are willing to develop it now.
Regards, Marius
In message Pine.LNX.4.61.0409151552180.4098@mag.sysgo.com 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.
folks give up their ATAGs in favour of PPCs bi_recs because of a
So this discussion should probably take place on lkml instead? ;-)
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.
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.
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
On Wed, Sep 15, 2004 at 03:24:20PM +0200, Wolfgang Denk wrote:
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
participants (6)
-
Dan Malek -
Eugene Surovegin -
Marius Groeger -
Pantelis Antoniou -
Robert Schwebel -
Wolfgang Denk