Re: U-Boot and kernel 2.6

On Fri, Jun 11, 2004 at 05:16:54PM +0300, Pantelis Antoniou wrote:

Wolfgang Denk wrote:

quoted

Dear Pantelis,

in message [ref] you wrote:

quoted

quoted

No, this is IMHO not a good idea. Some of the information that  needs
to  be  passed to the kernel is not contained in the envrionment, and
does not belong there.

I'm just talking about augmenting the information provided by bd_t.

Again, no. It makes no sense to implement two  (or  more)  interfaces
for  the  same  purpose.  Let's  do it once, and right. It has become
clear that the bd_t stuff is not flexible enough, so let's get rid of
it and replace it, instead of adding more crap^H^H^H^H stuff  on  top
of it.

quoted

And it's not just things that the kernel needs, it can be used to
pass information to the user-space applications.

But this is nothing now. You have always been able to read and  write
the  U-Boot  environment  from applications. But this is a completely
unrelated topic.

Similarly it's trivial to parse /proc/cmdline by a script or  program
to  extract any information you might be looking for. But again, this
has nothing to do with  the  way  how  the  boot  loader  passes  the
required information to the kernel.

quoted

Reading the environment from flash is not correct because the
variables might be modified by the boot sequence but not commited.

This depends  on  what  you  are  doing.  Of  course  it  is  in  the
responsibility  of  the user to define which data to use, and when or
where to place a "setenv" in the boot script (if really needed). "Not
correct" is just your opinion for a very specuific mode  of  usage  -
which  just  indicates the problem: the U-Boot environment is NOT the
right place to look for the information you are after.

OK, lets look at the very simple problem of having two
ethernet interfaces. From where do I get the ethernet
mac addresses? Modifying bd_t with defines is gross.
Putting everything on the kernel command line results in
an unreadable command line.

The 98%-in-2.6 answer today is to pass in BI_BOARD_INFO, a
board-specific blob of information, which is what boards like the
prpmc260 (only 2_4_devel right now since it's a gt64x60 board that needs
cleaner generic code for 2.6, but anyhow..).

... kicking myself for getting into this thread now, no doubt.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/