PCI drivers - BAR addresses
dnpaterson at gmail.com
Mon Oct 28 11:38:16 UTC 2013
On 25 October 2013 20:26, Daniel Hellstrom <daniel at gaisler.com> wrote:
> David Paterson <dnpaterson at gmail.com> wrote:
> >Hi Daniel,
> >After a bit of experimenting with the new version of RTEMS, I have a
> >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: 80040800-800409ff [PCIADR 80040800]
> > IO32: fff20000-fff200ff [PCIADR fff20000]
> >MEMIO: 80000000-8003ffff [PCIADR 80000000]
> >MEMIO: 80040000-800407ff [PCIADR 80040000]
> >However, with the little-endian define, I get :-
> > IO32: fff2000c-fff2000f [PCIADR fff2000c]
> > IO32: fff20008-fff2000b [PCIADR fff20008]
> > IO16: fff20004-fff20007 [PCIADR fff20004]
> > IO32: 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: 80040800-800409ff [PCIADR 80040800]
IO32: fff20000-fff200ff [PCIADR fff20000]
MEMIO: 80000000-8003ffff [PCIADR 80000000]
MEMIO: 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
>As a final query, I'm also looking for a way to determine the RTEMS
>at build time, e.g. as a defined constant, something like the Linux
>"KERNEL_VERSION_CODE". I noticed the latest RTEMS I downloaded
>had changed a number of functions in the API, and in order to support
>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-126.96.36.199(SPARC/w/FPU/leon3)" which looks a bit wrong, since I'm
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 188.8.131.52, 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users