<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi Daniel,<br><br></div>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.<br><br></div>
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.<br><br></div>Without this addition, I see the reported BAR registers for our card as :-<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>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></div>which looks very odd, and not really sensible BAR addresses at all.<br>
<br></div><div>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.<br>
</div><div><br></div>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.)<br>
<br></div>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.<br>
<br></div>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.<br>
<br></div>Best regards,<br><br>David<br><br><div><div><div><div><div><div><div><div><div><div><div><div class="gmail_extra"><br></div></div></div></div></div></div></div></div></div></div></div></div></div>