<div dir="ltr">Hi Daniel,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On 25 October 2013 20:26, Daniel Hellstrom <span dir="ltr"><<a href="mailto:daniel@gaisler.com" target="_blank">daniel@gaisler.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<div class="im">
<br>
David Paterson <<a href="mailto:dnpaterson@gmail.com">dnpaterson@gmail.com</a>> wrote:<br>
>Hi Daniel,<br>
><br>
>After a bit of experimenting with the new version of RTEMS, I have a<br>
>couple<br>
>of follow-up questions I hope you can help with.<br>
><br>
>I started with the "rtems-pci" sample, and added in the "#define<br>
>LITTLE_ENDIAN_PCI_SYSTEM" as you suggested, but that didn't have the<br>
>expected result.<br>
><br>
>Without this addition, I see the reported BAR registers for our card as<br>
>:-<br>
><br>
>MEMIO[0]:  80040800-800409ff [PCIADR 80040800]<br>
> IO32[1]:  fff20000-fff200ff [PCIADR fff20000]<br>
>MEMIO[2]:  80000000-8003ffff [PCIADR 80000000]<br>
>MEMIO[3]:  80040000-800407ff [PCIADR 80040000]<br>
><br>
>However, with the little-endian define, I get :-<br>
><br>
> IO32[0]:  fff2000c-fff2000f [PCIADR fff2000c]<br>
> IO32[1]:  fff20008-fff2000b [PCIADR fff20008]<br>
> IO16[2]:  fff20004-fff20007 [PCIADR fff20004]<br>
> IO32[3]:  fff20000-fff20003 [PCIADR fff20000]<br>
><br>
>which looks very odd, and not really sensible BAR addresses at all.<br>
</div>Yes it does.<br>
<br>
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<br>

. As I mentioned before the GRPCI driver have no ability to turn on bytetwisting just to turn off..<br></blockquote><div><br></div><div>D'oh!!  I should have thought to try that.  A quick test this morning with a clean restart now gives me BAR addresses :- <br>
<br>   MEMIO[0]:  80040800-800409ff [PCIADR 80040800]<br>    IO32[1]:  fff20000-fff200ff [PCIADR fff20000]<br>   MEMIO[2]:  80000000-8003ffff [PCIADR 80000000]<br>   MEMIO[3]:  80040000-800407ff [PCIADR 80040000]<br><br></div>
<div class="h5">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.<br><br> >As a final query, I'm also looking for a way to determine the RTEMS<br>

>version<br>
>at build time, e.g. as a defined constant, something like the Linux<br>
>"KERNEL_VERSION_CODE".  I noticed the latest RTEMS I downloaded<br>
>(1.2.12)<br>
>had changed a number of functions in the API, and in order to support<br>
>users<br>
>on different version we'll likely have to use a similar approach to out<br>
>Linux driver, using "#if RTEMS_VERSION > ????" sections to ensure the<br>
>correct API functions are called.  BTW, printing the version using<br>
>rtems-4.9.99.0(SPARC/w/FPU/leon3)() gives<br>
>"rtems-4.9.99.0(SPARC/w/FPU/leon3)" which looks a bit wrong, since I'm<br>
>using 4.10.<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>

<br>
What API has changed? Which version did you run before?<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br>
</div><div><br></div></div>Thanks for the help with this,<br><br></div><div class="gmail_extra">David<br><br></div></div></div>