Xilinx IP core drivers for RTEMS- diff attached

Keith Robertson kjrobert at alumni.uwaterloo.ca
Tue Dec 5 22:21:39 UTC 2006

gregory.menke at gsfc.nasa.gov wrote:
> Hi,
> I finally got back to some long-needed config management on the gen405
> bsp.  I assembled the diffs against, the file is attached for
> review.

Thanks for this Greg.

> I hesitate to just check them in as some of the changes related to
> uarts, fpu and memory map are highly idiosyncratic and I don't want to
> mess up other people's work.  I think a compromise patch might make the
> most sense, where I set up a diff that preserves the general character
> of the bsp; base addresses, etc.. but gets in the updated drivers.

I'm in favour of this being checked straight into a new xilinx or virtex 
405 bsp.  This could be a straight branch of the gen405 bsp with the 
combination of your and my changes applied.  This can be done without 
breaking any existing clients and allows us a simpler merge/update 
procedure.  Does this sound ok to you?

> Our bsp was peculiar in that the 405 units have 4 uarts and no fpu at
> all, meaning, the entire toolchain has to be compiled with -msoft-float
> to ensure nothing at all in newlib or above uses fp registers- the
> va_args are problematic since the ppc ABI allows fpu registers to be
> used when handing variable arguments.  

Hmmm.. I'm quite interested in this.  We don't have a fpu either 
(straight xilinx virtex2/4 ppc405) and I haven't given gcc the 
-msoft-float option.  However, despite some searching through assembly 
listings, I've never found any fp instructions/registers being emitted. 
  We've also had a number of different board variants in use for well 
over a year with no illegal instruction exceptions and the like.  ISTR 
Till and others have problems with this on the higher spec ppc's. 
However, until now I didn't now it was a problem on the ppc405.

Did you find cases where newlib/va_args (both of which we're also using) 
generated fp instructions?

 > I think it is this issue that
 > generally forces all PPC tasks to be floating point- its quite an
 > annoying architectural property.

I'm confused.  If you compiled with -msoft-float then presumably the 
tasks don't need to be floating point as no special registers would need 
to be saved during task switches?  Do I not fully understand something?

To summarise, we are successfully using the virtex ppc405 with:

- no explicit c floating point types
- no fpu
- no floating point tasks
- no -msoft-float
- with newlib
- with va_args
- with rtems' gcc-3.2.3

and I haven't (yet) found any fp instructions being generated.

Have I just got lucky and this is an issue I really need to look into?

> So I'd like to propose that folks interested in the Virtex 4 gen405 bsp
> family have a look at the diffs and respond with issues & changes and
> hopefully I can commit something that doesn't cause too much trouble.

Your diffs don't include the any changes/additions for _init/_fini.  See 
http://www.rtems.com/ml/rtems-users/2005/july/msg00008.html and related 
posts for more info.

Have you got this port to work successfully without this patch?  If so, 
I'd be quite keen to understand how.



More information about the users mailing list