Xilinx IP core drivers for RTEMS- diff attached

[Keith Robertson]

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 4.6.99.3, 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.

Cheers.

Keith