Memory layout question

[Paul Mackerras]

Oliver Korpilla writes:

> This seems to work fine and dandy on the x86, and there seems to be
> something wrong on the PowerPC.

Well, first, what source tree are you using?  What kernel version?

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

That sounds truly weird.  What is the whole message that gets printed?
I suggest you add a printk to __ioremap to print the values of
high_memory and virt_to_phys(high_memory).

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

You would think so.

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

You can in fact dereference the return value from __ioremap, but it is
generally not a good idea unless you know that what you are accessing
is well-behaved memory.  PowerPC processors can reorder loads and
stores unless you put barriers in to prevent that, and read/write[bwl]
include barriers for that reason.

Paul.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/