PCI drivers - BAR addresses

[David Paterson]

Hi Daniel,

On 25 October 2013 20:26, Daniel Hellstrom <daniel at gaisler.com> wrote:

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

D'oh!!  I should have thought to try that.  A quick test this morning with
a clean restart now gives me BAR addresses :-

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

which is the same as before without byte-twisting, but now reading from
these gives me access to the device registers :-)  Thanks for the help on
this.

>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'm using the pre-compiled 1.2.12 version (we're hoping not to have to
rebuild the kernel).  I've just noticed the copy'n'paste error in my
previous message - the function I'm calling to print the version is
"rtems_get_version_string()", and it's this that seems to be giving an odd
result.  However, for compile-time selection I can use the "RTEMS_VERSION"
define you mentioned in your other message.

I haven't looked in detail at the changes to the API yet, but will work
through them today.  We've previously been using version 1.1.99.10, and the
first change I noticed when rebuilding the driver was that the function
"rtems_drvmgr_init()" is now called "drvmgr_init()".  There probably aren't
too many differences, and hopefully they'll just be minor ones, so we
should be able to get a driver working with the latest build quite soon.

Thanks for the help with this,

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