PCI drivers - BAR addresses

[David Paterson]

Hi Daniel,

After a bit of experimenting with the new version of RTEMS, I have a couple
of follow-up questions I hope you can help with.

I started with the "rtems-pci" sample, and added in the "#define
LITTLE_ENDIAN_PCI_SYSTEM" as you suggested, but that didn't have the
expected result.

Without this addition, I see the reported BAR registers for our card as :-

MEMIO[0]:  80040800-800409ff [PCIADR 80040800]
 IO32[1]:  fff20000-fff200ff [PCIADR fff20000]
MEMIO[2]:  80000000-8003ffff [PCIADR 80000000]
MEMIO[3]:  80040000-800407ff [PCIADR 80040000]

However, with the little-endian define, I get :-

 IO32[0]:  fff2000c-fff2000f [PCIADR fff2000c]
 IO32[1]:  fff20008-fff2000b [PCIADR fff20008]
 IO16[2]:  fff20004-fff20007 [PCIADR fff20004]
 IO32[3]:  fff20000-fff20003 [PCIADR fff20000]

which looks very odd, and not really sensible BAR addresses at all.

I'm not 100% sure that the problem is related to byte-twisting anyway.  If
we write values into the BARs (e.g. 0xa0000000 etc.) then we can read the
device registers successfully, and in the correct endianness.  It seems to
be something to do with initialisation, and getting the driver manager to
set the BAR values correctly.

I'm also getting a problem if I try to enable the simple PCI driver in
rtems-pci.c (by setting the vendor and device ID, and enable the
"CONFIGURE_DRIVER_CUSTOM1" definition).  The program crashes immediately on
start, with no diagnostics.  (The previous version works OK.)

As a final query, I'm also looking for a way to determine the RTEMS version
at build time, e.g. as a defined constant, something like the Linux
"KERNEL_VERSION_CODE".  I noticed the latest RTEMS I downloaded (1.2.12)
had changed a number of functions in the API, and in order to support users
on different version we'll likely have to use a similar approach to out
Linux driver, using "#if RTEMS_VERSION > ????" sections to ensure the
correct API functions are called.  BTW, printing the version using
rtems-4.9.99.0(SPARC/w/FPU/leon3)() gives
"rtems-4.9.99.0(SPARC/w/FPU/leon3)" which looks a bit wrong, since I'm
using 4.10.

I've been working mostly with the sample programs to investigate this, but
I'll have to update our driver code for the new RTEMS 1.2.12 API changes.
Once I get this done I can test in a more realistic environment.

Best regards,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20131025/0abfc894/attachment-0001.html>