Xilinx IP core drivers for RTEMS- diff attached

[gregory.menke at gsfc.nasa.gov]

Robert S. Grimes writes:
 > Hi Keith, Pete, Greg, et. al.
 > 
 > This has finally bubbled up to the top for me, and I am finally getting back
 > to the task at hand - getting RTEMS up on Virtex-4 FX60.
 > 
 > >  >> Keith wrote:
 > > >> I'm in favour of this being checked straight into a new xilinx or
 > > >> virtex 405 bsp...
 > >  >
 > >  > Pete wrote:
 > > > I also vote for a separate BSP.
 > I agree - separate BSP.  But, maybe I'm a bit off on a tangent here, but
 > there is another issue I've been thinking about over the past several
 > months.  The V2/V4 really don't represent simple boards, in the BSP sense.
 > So starting a new BSP may not be sufficient for all users, unless we are
 > willing/able to define a "standard platform".  For example, I personally
 > don't like the default naming for components that Xilinx EDK generates.
 > Another example, address generation may vary.  Or maybe I'm looking at this
 > wrong, and what we really will need to do is define the constraints on the
 > EDK design, instead of the other way around?  Seems a little odd, at first -
 > the BSP defining the "board", instead of the other way 'round, but is this
 > the way to go?


I like the new bsp idea as well.  Maybe the thing to do is create a
"virtex4" bsp containing a copy of the gen405 bsp as-is, then I could
check in my patches against the new virtex bsp.

Given the intimate relationship with EDK, it might be desirable to set
up an edk header file "import" directory in the bsp so selected .h files
from a given user's EDK project can be incorporated.

Regards,

Greg