Hello,

> The address used for DMA is physical memory address. Do you say
> that PCI and CPU see different physical memory adresses? That's
> quite weird.

Yes, the memory is seen at 0x00000000 (physical) by the CPU, and 0x80000000
from the PCI side of the bridge. Likewise, PCI memory address 0x00000000 is
seen at 0xC0000000 (physical) by the CPU, and PCI I/O address 0x00000000 is
seen at 0x80000000 (physical) by the CPU. The first part of the PCI I/O space
is then normally reserved for the PCi-ISA bridge, so, CPU addresses starting at
0x80000000 are the ISA space. There's another address on the CPU side for
generating PCI config cycles.

PC programmers will wonder why it is all so complex; those of us that have used
PPC systems for a while are used to it (I've been working with embedded PPC
devices now since the mid-1990's starting with an MVME-1604 system - and they
have a PCI-VME bridge to add another layer of trsnslations ;-). It basically
comes down to the fact that PCI is an alien bus for PPC, and the bridge must
try to make it fit into the PPC world and still work. 
 
The bridge on this particular system, an IBM 82660, does have a mechanism for
duplicating the CPU's memory at PCI addresses starting at zero, but it needs to
be set by pulling a pin on the bridge chip high - there's no software control
over that feature.

> Isn't it just bug in htole32() in handling of the
> MSB or somewhere in the DMA code?

The byte swapping works a treat. I think that the problem is in the 
mbuf-specific DMA routine for the PPC. I can only assume that the other systems
using this haven't seen the problem because their bridge chips are setup to
keep the CPU's memory at PCI address zero too. The mvmeppc is one I would be
most suspect about... has anybody tried this with -current?

Rgds,
John...


=====
Rate Corporate America at http://exec-ratings.bluedonkey.org

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com