Memory layout question
Oliver Korpilla
okorpil at fh-landshut.de
Sun May 16 22:57:36 EST 2004
Hello!
I'm currently trying out the VMIC Tundra Universe II driver, a PCI-VME bus
bridge quite common in embedded devices (from VMIC and Motorola). VMIC
manufactures mostly x86 boards, but I try to use the driver on a MVME5500
with 7455 Motorola PPC.
There seems to be a memory problem involved, as follows:
The device will react if a PCI cycle contains addresses stored in its
device registers. If you tell the device, that it has a window starting
from 0x40000000 with size 0x100000, it will try to satisfy requests on the
bus for that addresses with data from the VME bus (the VME address, that
is separate from the PCI address, is stored in the device registers as
well).
This seems to work fine and dandy on the x86, and there seems to be
something wrong on the PowerPC.
The device driver module uses allocate_resource (&iomem_resource, ...... )
to request a set of physical addresses, and uses ioremap_nocache to map
those addresses to virtual ones. Idea behind this is, that any request to
the I/O memory will trigger bus cycles, and those bus cycles will be
catched by the device.
There is no actual I/O memory involved in the device - its registers are
read and written elsewhere. The addresses are only used to trigger bus
accesses.
Well, guess what, those accesses don't happen. While the DMA part of the
driver happens to work (relying on a different mechanism), this fails.
Actually the addresses returned by allocate_resource seem to come from
system memory, because ioremap_nocache logs a debug statement that is only
triggered if the remapping is below the high_memory bound. (And there
already seems to be a virtual address associated with it - physical
0x40000000 is RAM 0xc<whatever> - kernel space, I guess)
But the address returned is 0x40000000 !! Isn't that the 2nd GB of address
space? My board only has 512 MB of storage, and is only upgradable to 1GB,
so shouldn't an address starting at 0x40000000 physically never be a
memory address and never be below the high_memory bound?
When calling allocate_resource you can already limit the range of possible
addresses - in my case default is 0x00000000 and 0xffffffff (no limit).
The value returned seems to be consistently 0x40000000. What could be a
safe value for the lower bound, say e.g. 0x80000000 or something?
Can I even dereference an I/O memory pointer on the PowerPC? (It can be
done on x86) I know, I know, I _should_ use readb and friends, but can it
be done? Or _must_ I strictly use the macros because it won't work the
other way round?
Thanks in advance,
Oliver Korpilla
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-embedded
mailing list