[PATCH] pc386 BSP PCI initialization fix [was: Re: PCI lookup issue: 3c905C-TX not found by RTEMS.]

[Joel Sherrill <joel@OARcorp.com>]

gregory.menke at gsfc.nasa.gov wrote:
> Karel Gardas writes:
>  > On Tue, 25 Jan 2005, Till Straumann wrote:
> 
>  > But the main question still remains: what's the prefered practice: i.e.
>  > PPC way or dec21140/if_fxp way of PCI initialization?
>  
> This is a long-standing disparity between the i386 bsps and the
> PowerPC bsps respective implementations of PCI and interrupt vectoring
> support.  Theres probably a more or less equal mass of code on each
> side of the fence, so reducing the two approaches into a single one is
> a fairly large job- not terribly complicated, but a good deal of
> highly detailed work is required to do it and test it and fix all the
> stuff which breaks.

I would suspect the PPC might have more code because there are
more BSPs.  But that's just a guess.

> Personally, I favor the PowerPC approach, its a bit more portable and
> generalizable, but the api is more complex.
> 
> But regardless I think we're stuck with the current state of affairs
> until some project/team comes along with the resources to get the
> PowerPC and i386 bsp's under the same roof for long enough to get it
> worked out.  I'd love to do or at least help with it, but its not
> something I can justify a big expenditure of time on at this point.  I
> imagine others are in a similar position.  
> 
> On the other hand, things change- I was able to fancy up the dec2114x
> driver, write the etherlink driver (porting and adapting bsd code),
> and enhance the PPC pci support a fair bit because of a project need.
> Something may well come out of nowhere to jumpstart the PCI
> unification.

I will again mention the "nibble at it" approach which works also.
It still takes effort but one person/team does not have to do it
all.

I had considered at one point making them use the same .h file
and ifdef'ing the differences on CPU.  Then work through this.
Ralf did a 1st step in this when he put a pci.h under cpukit.
It is based upon the PowerPC one with soms modifications.

Here are all the files named pci.h:

./c/src/lib/libbsp/i386/shared/pci/pcibios.h
./c/src/lib/libbsp/powerpc/mvme5500/pci/pci.h
./c/src/lib/libbsp/powerpc/ppcn_60x/include/pci.h
./c/src/lib/libbsp/powerpc/shared/bootloader/pci.h
./c/src/lib/libbsp/powerpc/shared/pci/pci.h
./cpukit/include/rtems/pci.h

My first step would be to unify libbsp/powerpc/shared/pci/pci.h
with cpukit/include/rtems/pci.h and then remove the libbsp/powerpc
one.

Then I would eliminate the powerpc/memv5500 one.

AFAIK the ppcn_60x could be ignored and put up for deprecation.
But it looks pretty easy to move to the standard PPC model.  So
I would probably take a swing at updating.

That leaves the bootloader version under the libbsp/powerpc.  That
would take looking at.

That leaves you with just the i386 and PPC variant to merge.

In general, when doing this type of API change, my rule is
very simple.  Make all changes to committed RTEMS CVS source
and make sure it compiles.  If code isn't submitted and in
the tree, then it does NOT exist.

This should be largely a mechanical transformation.


> Gregm
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985