[ECOS] PCI Address Mapping

Nick Garnett nickg@redhat.com
Mon Jan 21 10:15:00 GMT 2002

"Robert Cragie" <rcc@jennic.com> writes:

> 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?

Assuming that BAR[0] is the memory base address and not the IO base
address, that is correct.

> 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.

The PC is somewhat rare in that the mapping between the PCI address
space and the CPU physical address space is 1-1 and not windowed. This
means that you can give a PCI device any address in memory, and it can
access that memory directly. Any peculiarities you may see in the
i82559 driver are there to cope with targets where this is not the
case. So, your assumptions above are largely true.

One important point to make, however, is that device drivers should
not use malloc(). If you look at the i82559 you will see that it has a
memory region reserved for it in the .ldi file and uses that for
allocating buffers.

> 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).

The caches are used in the IA-32, but the architecture has very
limited support for manipulating them. Also, since all
DMA/PCI/whatever accesses are cache-coherent for historical reasons,
there is no need to manipulate the caches. Hence I decided to save a
bit of effort and not implement the macros.

Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

More information about the Ecos-discuss mailing list