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?

Cheers.

Keith




More information about the users mailing list