PCI drivers - BAR addresses

[Daniel Hellstrom]

Hi,


David Paterson <dnpaterson at gmail.com> wrote:
>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.
Yes it does.

Thats sound strange, since on the leon4-itx board you should enable bytetwisting. Note that if you have run a previous image before without resetting the board or used GRMON to turn off bytetwisting before the RTEMS app you may end up in a funny situation 
. As I mentioned before the GRPCI driver have no ability to turn on bytetwisting just to turn off..


Just before creating the release I ruan the rtems-shell app on an itx board successfully. One can list the pci cfg space using the 'pci ls' and 'pci' command from RTEMS. My guess is that should be the same pci setup as in rtems-pci though.


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

Thats wrong, I will have a look at it. Have you built the kernel yourself or used the precompiled? Rcc 1.2.12 is rtems-4.10.2.

What API has changed? Which version did you run before?

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

Ok.

Daniel

>
>Best regards,
>
>David

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.