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

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

[Pantelis Antoniou]

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 

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

[Wolfgang Denk]

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

-- 
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

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

[Pantelis Antoniou]

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

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

[Wolfgang Denk]

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

-- 
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. Barton

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

[Pantelis Antoniou]

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

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

[Wolfgang Denk]

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

-- 
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

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

[Eugene Surovegin]

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.

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

[Dan Malek]

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

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

[Marius Groeger]

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

-- 
Marius Groeger <mgroeger@sysgo.com>
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

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

[Wolfgang Denk]

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

-- 
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.

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

[Pantelis Antoniou]

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

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

[Wolfgang Denk]

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

-- 
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."

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

[Marius Groeger]

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.

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

[Wolfgang Denk]

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

-- 
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

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

[Robert Schwebel]

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
-- 
 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