PCI drivers - BAR addresses

[David Paterson]

Thanks Daniel, very useful information.

This sounds like it will be a big help in getting the board configuration
correct, and I'll let you know how it works out.  If I have further queries
I'll copy in support as well.

Regards,

David P.



On 24 October 2013 13:52, Daniel Hellstrom <daniel at gaisler.com> wrote:

> Hello David,
>
> Please send your LEON specific questions to support at gaisler.com. I have
> set support in CC.
>
> Please see my comments embedded below.
>
>
>
> On 10/23/2013 04:13 PM, David Paterson wrote:
>
>> Hi all,
>>
>> I'm working on a driver for a PCI card (our own design of network device)
>> and have run into a bit of a problem in accessing the device registers via
>> the BAR's.
>>
>> We're currently developing for a LEON4 system, using the Gaisler
>> GR-LEON4-ITX board, and now have most of the driver structure in place
>> (based on a working Linux version).  Accessing the configuration registers,
>> e.g. via pci_read_config_dword etc. works fine, but accessing other
>> registers via memory mapping at the addresses in the card's BAR registers
>> isn't working at all.
>>
>
> Please make sure that the byteTwisting option to the GRPCI driver is
> enabled on the ITX board. Note that the GRPCI driver assumes that the byte
> twisting bit is initialized as after a reset. In the latest RCC-1.2.12
> distribution there is an example of enabling byte twisting in
> config_leon3_drvmgr.c by adding the "#define LITTLE_ENDIAN_PCI_SYSTEM"
> before config.c from the example you are compiling located in
> /opt/rtems-4.10/src/samples.
>
>
>
>
>> The addresses assigned, either by the BIOS or possibly RTEMS start-up,
>> don't appear to be correct, and in fact it looks like there's a conflict
>> with the LEON4 GRPCI address space - both our card and the GRPCI controller
>> are operating in the 0x80000000 range.
>>
>
> There is no BIOS in LEON, unless you have added you own bootloader with
> PCI support. RTEMS is normally responsible to auto-probe and aut-configure
> the PCI bus over PCI configuration space.
>
>
>
>
>> If we assign BAR addresses manually (e.g. 0xa0000000) we can read and
>> write registers successfully, but at the moment we're just using arbitrary
>> addresses which we hope don't conflict with anything else.  For a working
>> driver we'll have to cope with multiple cards in a system, and also other,
>> unknown, devices being present, so we need to find a way to set up
>> "correct" addresses, which are unique to each card.
>>
>
>
>> Is there a way to get the BAR addresses automatically assigned and
>> written to the card, or, if not, a way to query the system as to which
>> addresses should be used?  I've been searching the code base and looking
>> through the documentation, but can't see any references to this sort of
>> thing.
>>
>
> It is possible to use the RCC PCI layer in three modes:
> Auto-configuration, Read-configuration (when you have a BIOS) or
> Static-configuration where the user provide a custom configuration (a
> static configuration description of a running system can be generated from
> pci command in RTEMS). Default is auto-configuration.
>
> Please try the rtems-pci.c or rtems-shell.c examples in RCC and add the
> "#define LITTLE_ENDIAN_PCI_SYSTEM" before including config.c. You can issue
> 'pci ls' from the RTEMS command shell to view the auto-configured PCI bus
> settings.
>
> Normally the LEON documentation is located in the RCC manual or the
> drivers manual, however the PCI library documentation has been added to the
> RTEMS C User manual found in /opt/rtems-4.10/doc/rtems/c_**user.pdf.
>
> Best Regards,
> Daniel Hellstrom
> Aeroflex Gaisler
>
>
>> Regards,
>>
>> David P.
>>
>>
>>
>> ______________________________**_________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/**listinfo/rtems-users<http://www.rtems.org/mailman/listinfo/rtems-users>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20131024/5cd144f1/attachment-0001.html>