Xilinx IP core drivers for RTEMS- Keith Robertson still around?

Keith Robertson kjrobert at alumni.uwaterloo.ca
Wed Nov 8 18:18:28 UTC 2006

gregory.menke at gsfc.nasa.gov wrote:
> I'm about ready with a bunch of pretty well tested gen405 changes
> against the RTEMS tree;
> - source & makefiles ported to cvs head
> - rewritten uart driver, supports multiple uarts, exploits full
>   configured tx fifo depth buffering, polling mode only.
> - considerably re-written soft core xilemac driver, supports up to 8
>   simultaneous instances of the mac with 32 or 64 bit packet fifos- no
>   DMA support yet.  No hard core mac support in this driver.
> - updated opc interrupt controller vectoring
> - updated and simplified runtime memory map (workspace & heap
>   allocations are better defined and more simply controlled).
> To bring up RTEMS on a Virtex 4 ppc, the only thing that needs doing is
> ensuring the given base addresses for the uart & interrupt controllers
> are specified.  For the soft mac, the address can be given in the driver
> control struct, others are for the moment hardcoded in bsp .h files.
> I was thinking I could send out a provisional .diff since these are more
> than simple changes, avoiding too much upheaval by commiting directly to
> the cvs tree.

Hi Greg.

I'd be interested in any/all of these updates if you're able to provide 
them at this point.  I've also significantly changed the soft core 
xilemac driver (32/64 bit fifo autodetection, much better code design, 
bug fixes), although it sounds like your changes incorporate that plus more.

I'm particularly interested in your rtems infrastructure changes, 
(makefiles, workspace/heap configuration, and the like) I was never 
particularly happy with the way the gen405 did all that.

Might we consider a new xilinx or virtex bsp rather than submitting to 
the gen405 one?

A couple of questions as well:

1) Is your updated port still using the old exception mechanism?
2) If you are using the new exception mechanism, do you handle/use the 
critical interrupt simultaneously with the external interrupt?  If not, 
have you given any consideration as to how to support it?



More information about the users mailing list