[RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code

[RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code

[Laurent Pinchart]

Hi everybody,

the Embedded Planet boards boot loader pass a string containing key/value 
pairs to the Linux loader code. That string is parsed in 
arch/ppc/simple/embed_boot.c.

The current implementation duplicates the parsing code once for each supported 
board. As I'm adding support for a new EP board (EP8248), I was wondering if 
it would be worth merging all those parsers together. This would reduce the 
source code size, but would be pointless at runtime as only one board support 
code is compiled in the kernel anyway.

Should I submit a patch, or leave the code as it is ?

Laurent Pinchart

Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code

[Dan Malek]

On Jan 25, 2006, at 3:15 AM, Laurent Pinchart wrote:

> Should I submit a patch, or leave the code as it is ?

Port Das U-Boot.


	-- Dan

Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code

[Laurent Pinchart]

> > Should I submit a patch, or leave the code as it is ?
>
> Port Das U-Boot.

Of course, that's another solution. We will use Das U-Boot for our custom 
design.

What I wanted to do here is completely different. As the board comes with a 
proprietary boot loader, I thought it would be interesting for future users 
to have the board supported in the vanilla kernel, like many other boards 
are. Is that a mistake ?

Laurent Pinchart

Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code

[Tom Rini]

On Wed, Jan 25, 2006 at 05:02:20PM +0100, Laurent Pinchart wrote:
> > > Should I submit a patch, or leave the code as it is ?
> >
> > Port Das U-Boot.
> 
> Of course, that's another solution. We will use Das U-Boot for our custom 
> design.
> 
> What I wanted to do here is completely different. As the board comes with a 
> proprietary boot loader, I thought it would be interesting for future users 
> to have the board supported in the vanilla kernel, like many other boards 
> are. Is that a mistake ?

No, that's good.  If you can cleanly merge the existing parsing code, by
all means please do so.  Thanks.

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

Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code

[Laurent Pinchart]

> No, that's good.  If you can cleanly merge the existing parsing code, by
> all means please do so.  Thanks.

Ok I will. On which kernel tree should I base my patches on ?

Laurent Pinchart

Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code

[Tom Rini]

On Tue, Jan 31, 2006 at 09:47:32AM +0100, Laurent Pinchart wrote:
> > No, that's good.  If you can cleanly merge the existing parsing code, by
> > all means please do so.  Thanks.
> 
> Ok I will. On which kernel tree should I base my patches on ?

I would suggest either Linus' current git tree or 2.6.16-rc1 if you don't
use git.  But please bear in mind that since this is a new feature (a new
board) it won't be submitted to Linus' tree until 2.6.17-rc1 opens up (and
if in that time, it becomes much easier to put this board under arch/powerpc
it should be done under there, instead).

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

Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code

[Peter Korsgaard]

>>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:

 Tom> I would suggest either Linus' current git tree or 2.6.16-rc1 if
 Tom> you don't use git.  But please bear in mind that since this is a
 Tom> new feature (a new board) it won't be submitted to Linus' tree
 Tom> until 2.6.17-rc1 opens up (and if in that time, it becomes much
 Tom> easier to put this board under arch/powerpc it should be done
 Tom> under there, instead).

I only recently moved from 2.4 to 2.6, so this may be a FAQ, but a
quick googling around didn't find anything.

What is this arch/ppc -> arch/powerpc about? Some kind of
consolidation of ppc and ppc64? What's the reason behind it and what
kind of time frame are we talking about? Is it related to the bd_t ->
flattened OF tree change?

Could someone post a few pointers to more information? 

-- 
Bye, Peter Korsgaard

Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code

[Jon Loeliger]

On Tue, 2006-01-31 at 14:31, Peter Korsgaard wrote:
> >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
> 
>  Tom> I would suggest either Linus' current git tree or 2.6.16-rc1 if
>  Tom> you don't use git.  But please bear in mind that since this is a
>  Tom> new feature (a new board) it won't be submitted to Linus' tree
>  Tom> until 2.6.17-rc1 opens up (and if in that time, it becomes much
>  Tom> easier to put this board under arch/powerpc it should be done
>  Tom> under there, instead).
> 
> I only recently moved from 2.4 to 2.6, so this may be a FAQ, but a
> quick googling around didn't find anything.
> 
> What is this arch/ppc -> arch/powerpc about? Some kind of
> consolidation of ppc and ppc64?

Exactly.

> What's the reason behind it

Eliminate duplicate code.  Share good code.
Improved modularity.  Leverage.  All the Good Stuff (tm).
Eliminate the bd_t mess.  You know.

> and what kind of time frame are we talking about?

In progress now.  All of the PPC64 ports are now officially
part of the "powerpc" arch.  There are two published PPC32
ports (MPC8349SYS and MPC8540ADS) that have been posted to
the list as being "merged" into the powerpc arch.  They are
still evolving a bit, though.

>  Is it related to the bd_t ->
> flattened OF tree change?

Yes.  New World Order says all arch/powerpc ports will 
use a common flat dev tree interface from boot loaders
unless honest OF is available.  The bd_t is obsolete.

> Could someone post a few pointers to more information? 

Read the "booting without open firmware" spec recently
patched from the DTC code tree to the linux doc directory
on the PPC64 list by Dave Gibson.

Read the Device Tree Compiler code itself too.

jdl