PCI drivers - BAR addresses

Daniel Hellstrom daniel at gaisler.com
Tue Oct 29 07:48:16 UTC 2013


Hello,

On 10/28/2013 05:40 PM, David Paterson wrote:
>
> On 28 October 2013 14:50, Daniel Hellstrom <daniel at gaisler.com <mailto:daniel at gaisler.com>> wrote:
>
>     Yes there are a lot PCI changes. We have implemented a PCI library located in cpukit/libpci. Now the cfg space identifier {int bus, int slot, int func} is substituted with pci_dev_t to reduce
>     the footprint of all PCI functions and callers. Now there are also I/O access routines.
>
>     grpci_* is the GRPCI specific implementation, it is better to use the new PCI library definitions defined in pci/access.h:
>
>     /* Configuration Space Access Read Routines */
>     extern int pci_cfg_r8(pci_dev_t dev, int ofs, uint8_t *data);
>     extern int pci_cfg_r16(pci_dev_t dev, int ofs, uint16_t *data);
>     extern int pci_cfg_r32(pci_dev_t dev, int ofs, uint32_t *data);
>
>     /* Configuration Space Access Write Routines */
>     extern int pci_cfg_w8(pci_dev_t dev, int ofs, uint8_t data);
>     extern int pci_cfg_w16(pci_dev_t dev, int ofs, uint16_t data);
>     extern int pci_cfg_w32(pci_dev_t dev, int ofs, uint32_t data);
>
>     /* Read a register over PCI I/O Space */
>     extern uint8_t pci_io_r8(uint32_t adr);
>     extern uint16_t pci_io_r16(uint32_t adr);
>     extern uint32_t pci_io_r32(uint32_t adr);
>
>     /* Write a register over PCI I/O Space */
>     extern void pci_io_w8(uint32_t adr, uint8_t data);
>     extern void pci_io_w16(uint32_t adr, uint16_t data);
>     extern void pci_io_w32(uint32_t adr, uint32_t data);
>
>
> Thanks Daniel, it's starting to look a bit closer to working now :-)
>
> I've made all the changes, and I can get my test driver and test program to build, but it's not initialising the driver.  Trying the sample "rtems-pci" program with the custom driver enabled shows 
> the same problem, which might give you an idea of what's going wrong.
>
> If I enable the "#define CONFIGURE_DRIVER_CUSTOM1" flag, then both my program and the sample fail with, e.g. :-

You must also update (which you probably also did):

/* CHANGE THIS !!! to match the DEVIC/VENDOR of your PCI board */
#define PCIID_VENDOR_CUSTOM 0x1186
#define PCIID_DEVICE_CUSTOM 0x4000


>
> grlib> load /opt/rtems-4.10-mingw/src/samples/rtems-pci
> section: .text at 0x40000000, size 180176 bytes
> section: .data at 0x4002bfd0, size 5520 bytes
> section: .jcr at 0x4002d560, size 4 bytes
> total size: 185700 bytes (19.8 Mbit/s)
> read 1100 symbols
> entry point: 0x40000000
> grlib> run
> IU in error mode (tt = 0x2b)
>  40016818  80a0a000   cmp  %g2
>
> Looking at a dump of the executable, this is near the start of "_CORE_mutex_Seize", if that helps in any way...

This is caused by the printf() in custom_pci_board_register, please change it to printk() instead. It is too early to call printk(). The code works if the drvmgr is initialized from the Init task, 
then printf() could have been used. I have updated the example for the next release. Thanks for the feedback!

Daniel

grmon2> bt

        %pc          %sp
   #0   0x40018b88   0x4ffffae8   <_API_Mutex_Lock+0x40>
   #1   0x40019f74   0x4ffffb48 <_Protected_heap_Allocate_aligned_with_boundary+0x8>
   #2   0x400143c8   0x4ffffba8   <malloc+0x48>
   #3   0x40005f74   0x4ffffc08   <__smakebuf_r+0xac>
   #4   0x40003b8c   0x4ffffcb0   <__swsetup_r+0xdc>
   #5   0x40005a48   0x4ffffd10   <__sfvwrite_r+0x20c>
   #6   0x400014e8   0x4ffffd70   <_puts_r+0x80>
   #7   0x40001354   0x4ffffdf0 <custom_pci_board_register_drv+0x8>
   #8   0x400119f0   0x4ffffe50 <_DRV_Manager_initialization+0x1c>
   #9   0x40018778   0x4ffffeb0 <rtems_initialize_data_structures+0xc0>
   #10  0x40009adc   0x4fffff10   <boot_card+0x74>
   #11  0x400010c0   0x4fffff80





More information about the users mailing list