This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: PCI Address Mapping


I have a similar situation, and reading this thread has made me wonder about
some things:

I am using PC motherboard, and I need to set up PCI accesses to a bespoke
networking device, which can be accessed as memory as a slave on the PCI
bus, but which also can be a bus master. I assumed to set up the slave
access part, I would essentially need to do the following to find one card
(shortened a bit):

    cyg_pci_device_id pci_dev;
    cyg_pci_device pci_dev_info;
    cyg_uint16 cmd;
    cyg_uint32 membase;

    cyg_pci_init();

    pci_dev = CYG_PCI_NULL_DEVID;

    if (cyg_pci_find_device(vendor_id,
                            device_id,
                            &pci_dev) == FALSE)
    {
        /* error */
    }

    cyg_pci_get_device_info(pci_dev, &pci_dev_info);

    if (cyg_pci_configure_device(&pci_dev_info))
    {
        /* OK */
    }
    else
    {
        /* error */
    }

    /* Enable IO and MEM access to the device */
    cyg_pci_read_config_uint16(pci_dev_info.devid, CYG_PCI_CFG_COMMAND,
&cmd);
    cmd |= CYG_PCI_CFG_COMMAND_IO|CYG_PCI_CFG_COMMAND_MEMORY;
    cyg_pci_write_config_uint16(pci_dev_info.devid, CYG_PCI_CFG_COMMAND,
cmd);

    membase = (cyg_uint32)pci_dev_info.base_map[0];

    /* etc. */

I now presume that 'membase' now points device's registers mapped into
memory space, and that the interrupt vector is also set up by
cyg_pci_configure_device() in 'pci_dev_info.hal_vector'. Initial cursory
tests seem to back this up. Is this all I have to do?

To set up the scatter/gather buffers for transferring data, I assumed that I
would only have to use malloc() to obtain the space, then I could pass the
addresses directly to the device which it can then use for its access. The
assumptions are based on the fact that AFAICT a flat memory model is used
and thus there is no problem with discontiguity or mapping bus to virtual
addresses, nor is there an issue with endianness for this device.

However, having read all that below, and looking at the i82559 code, I am
wondering if my assumptions are valid or whether I am missing something. And
what is the impact of the data cache? Again, looking at the i386 HAL, the
cache doesn't seem to be used, as the macros are void. (FWIW, I use
__get_free_pages(GFP_ATOMIC, order) (the guts of kmalloc()) in the Linux
Kernel, and that seems to work fine).

Unfortunately, I am not too familiar with the details of the IA-32
architecture. Any help appreciated.

Robert Cragie, Design Engineer

Direct: +44 (0) 114 281 4512
________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
www.jennic.com  Tel: +44 (0) 114 281 2655   Confidential

> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Michael Kelly
> Sent: 18 January 2002 19:06
> To: Jonathan Larmour
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] PCI Address Mapping
>
>
> Jonathan,
>
> At 05:45 PM 1/18/2002 +0000, Jonathan Larmour wrote:
> >Michael Kelly wrote:
> > >
> > > Hi,
> > >
> > > Well I found my answer, and it's a bit ugly!
> > >
> > > We have a hard coded window defined in the .mlt file as
> > > pci_window.  This insures that malloc won't take it.  Then
> > > for the 82559 driver, we simply use the following defines
> > > in the .inl file:
> > >
> > > #define CYGHWR_INTEL_I82559_PCI_MEM_MAP_BASE 0x01F00000
> > > #define CYGHWR_INTEL_I82559_PCI_MEM_MAP_SIZE 0x0010000
> > >
> > > This means that one driver eats up all of the local memory
> > > space assigned for PCI accesses.  If you have a second
> > > PCI device you're out of luck.  Unless you want to write your
> > > own heap manager.
> > >
> > > Is the correct?  Is their any chance of a real heap manager
> > > for PCI bus mastering devices?
> >
> >We've been talking about this internally - there is certainly a need for
> >it, and the allocator can be very simple (it never needs to free[1]). I
> >don't believe anyone is working on it though.
>
> As a small consolation, you can have multiple devices of the
> same type since the 82559 driver implements a simple heap
> manager as would any other generic device.
>
> It is not horrible to simply create one larger pci_window and
> give only part of it to each driver.  Again, crude, but effective
> if you have only a few bus mastering devices.  I suspect
> that for the majority of embedded systems, this is not
> unreasonable.
>
> Michael
>
>
> Michael J. Kelly
> VP Engineering/Marketing
> Cogent Computer Systems, Inc.
> 1130 Ten Rod Road
> Suite A-201
> North Kingstown, RI 02852
> tel:401-295-6505 fax:401-295-6507
> www.cogcomp.com
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]