[U-Boot-Users] Where to put semi-common files?

[U-Boot-Users] Where to put semi-common files?

[Jon Loeliger]

Wolfgang,

We are needing to introduce the 8544 DS board soon.
It's board is essentially identical to the board in the 8641HPCN.
Both boards have an FPGA on them that controls carious system
parameters and configuraiton parts, including the reset logic
that we've already discussed.  That FPGA is called "PIXIS" and
has support code for it already added to the 8641hpcn's directory.

Naturally, we need exactly the same code for the 8544 DS board
now too.  But it can't be in a shared board directory, nor are
the two SoC parts even in the same CPU families.  One is 85xx,
the other is 86xx.  The FPGA isn't really a device for which one
might think "driver/", so that likely isn't the right directory
either.  Perhaps lib_ppc/?

Actually, there are other very similar bodies of code that are
shared across boards and CPU families (for example, the DDR setup
code in spd_sdram.c).

Do you have a good place where you would like to see this sort
of shared code?  It is easy enough to pick up just the parts that
are wanted during compilation due to CONFIG options, but we need
a directory from which we can share these sources.

Recommendations?

Thanks,
jdl

[U-Boot-Users] Where to put semi-common files?

[Stefan Roese]

Hi Jon,

On Tuesday 03 April 2007 21:09, Jon Loeliger wrote:
> We are needing to introduce the 8544 DS board soon.
> It's board is essentially identical to the board in the 8641HPCN.
> Both boards have an FPGA on them that controls carious system
> parameters and configuraiton parts, including the reset logic
> that we've already discussed.  That FPGA is called "PIXIS" and
> has support code for it already added to the 8641hpcn's directory.
>
> Naturally, we need exactly the same code for the 8544 DS board
> now too.  But it can't be in a shared board directory, nor are
> the two SoC parts even in the same CPU families.  One is 85xx,
> the other is 86xx.  The FPGA isn't really a device for which one
> might think "driver/", so that likely isn't the right directory
> either.  Perhaps lib_ppc/?

I would suggest to start moving your Freescale boards ports into a freescale 
directly:

board/freescale/mpc8349itx/
	       /mpc832xemds/
...

Then you could add a common freescale directory, as done already for "esd" 
or "prodrive":

board/esd/common/

If you take a look at this directory you will notice here some common FPGA 
code (and others stuff too). This is not CPU specific and not a generic 
driver, so it shouldn't be moved to the cpu/xxx or drivers/xxx directories.

Any other opinions?

> Actually, there are other very similar bodies of code that are
> shared across boards and CPU families (for example, the DDR setup
> code in spd_sdram.c).

spd_sdram should be moved to cpu/xxx/ since it's cpu specific and not really a 
driver. We have this for cpu/ppc4xx already in plance for all sorts of 4xx 
SDRAM controllers.

> Do you have a good place where you would like to see this sort
> of shared code?  It is easy enough to pick up just the parts that
> are wanted during compilation due to CONFIG options, but we need
> a directory from which we can share these sources.
>
> Recommendations?

Please see above. Just my 0.02$.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
=====================================================================

[U-Boot-Users] Where to put semi-common files?

[Ben Warren]

Stefan/Jon,

On Tue, 2007-04-03 at 21:29 +0200, Stefan Roese wrote:
> I would suggest to start moving your Freescale boards ports into a freescale 
> directly:
> 
> board/freescale/mpc8349itx/
> 	       /mpc832xemds/
> ...
> 
> Then you could add a common freescale directory, as done already for "esd" 
> or "prodrive":
> 
> board/esd/common/
> 
> If you take a look at this directory you will notice here some common FPGA 
> code (and others stuff too). This is not CPU specific and not a generic 
> driver, so it shouldn't be moved to the cpu/xxx or drivers/xxx directories.

This seems like the right approach.  This is definitely a 'board' thing,
not a 'driver' or 'cpu' thing.  The important thing to remember is that
the Freescale evaluation board ports are used as starting points for
many other designs that won't have this particular FPGA, so we need to
make it obvious that it's particular to the board.  Good initiative on
Jon's part in removing duplication.

regards,
Ben