PCI drivers - BAR addresses

[Daniel Hellstrom]

Ok, thanks for letting me know.

You can have a look at the changelog, I think the 1.1.99.17 introduced changes in the drvmgr API names, the changelog describe a way to update some of the changes:
     sed -e 's/rtems_drvmgr_dev_info/drvmgr_dev/g' \
         -e 's/rtems_drvmgr_bus_info/drvmgr_bus/g' \
         -e 's/rtems_drvmgr_drv_info/drvmgr_drv/g' \
         -e 's/rtems_drvmgr_/drvmgr_/g' -i FILE
The configuration (for example drvmgr_leon3_config.c) has changed too to avoid unnecessary malloc() calls during initialization.

Daniel


On 10/28/2013 12:38 PM, David Paterson wrote:
> Hi Daniel,
>
> On 25 October 2013 20:26, Daniel Hellstrom <daniel at gaisler.com <mailto:daniel at gaisler.com>> wrote:
>
>     Hi,
>
>     David Paterson <dnpaterson at gmail.com <mailto: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
>