U-Boot and kernel 2.6

[Tom Rini]

On Fri, Jun 11, 2004 at 05:16:54PM +0300, Pantelis Antoniou wrote:
>
> Wolfgang Denk wrote:
>
> >Dear Pantelis,
> >
> >in message <40C9B249.4070905 at intracom.gr> you wrote:
> >
> >>>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.
> >
> >
> >>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.
> >
> >
> >>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/