Re: mmap on 440gx

On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote:

On 6/16/05, Matt Porter [off-list ref] wrote:

quoted

On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote:

Thanks for taking the time to reply.

quoted

quoted

I've been struggling with implementing mmap on a 440gx-based custom
board.  I have been able to use ioremap(), but we really need a mmap()
for our software.  The kernel is 2.4.18 (TimeSys 4.0).

There are some special things done for handling [io]_remap_page/pfn_range
on other vendor kernels and the current mainline kernel.  I'm not sure
if your vendor kernel addressed them since it would be a vendor-specific
patch in that timeframe.  The special things are due to 36-bit
addressing.

quoted

I'm trying to access one of our FPGA's located at 0x50000000.  Offsets

Let's start at the beginning.  How do you have FPGA's at 0x50000000?
that address falls with the fix DDR SDRAM area on the 440GX memory
map. All peripheral and EBC space is mapped by 4GB. You lost me
right here. Oh wait, are you referring to the least significant 32-bits
of the physical mapping. It's not really at 0x50000000.

Of course, you're correct.  The 36-bit base address is 0x1_0000_0000. 
It is mapped to the 32-bit address 0x5000_0000.

That's an interesting way to look at it but there isn't really a
"mapping".  You have configured a EBC chip selects to decode at
1_5000_0000.

Should I pass the 36-bit address to remap_page_range()?

No, it takes a 32-bit physical address and "fixes it up" using
the fixup_bigphys_addr() method.  Double check that the trap ranges
are correct for you board port.  They need to be modified to add
the appropriate MS 4-bit.  Since ioremap() also uses
fixup_bigphys_addr() to "fixup" 32-bit addresses to 36-bit,
it should just work. 

For what it's worth, __pa(0x5000_0000) returns 0x9000_0000.

Sure, you just asked it to subtract KERNELBASE from a physical address.
Don't use __pa() in drivers. That's expected behavior. Why are
you doing that?
 

quoted

You need something like the bigphys_remap patch for 2.4 that can be
found at ftp://source.mvista.com/pub/linuxppc/

I just checked the source, and that patch has indeed been applied.

Ok, assuming it's all correct then I don't know why it does work
for you in your vendor tree. Have you asked Timesys for help?

Put some debug statements throughout fixup_bigphys_addr() to see
what's going on.

-Matt

On 6/17/05, Matt Porter [off-list ref] wrote:

On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote:

quoted

On 6/16/05, Matt Porter [off-list ref] wrote:

quoted

On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote:

Thanks for taking the time to reply.

quoted

quoted

I've been struggling with implementing mmap on a 440gx-based custom
board.  I have been able to use ioremap(), but we really need a mma=

p()

quoted

quoted

quoted

for our software.  The kernel is 2.4.18 (TimeSys 4.0).

=20
=20

quoted

For what it's worth, __pa(0x5000_0000) returns 0x9000_0000.

=20
Sure, you just asked it to subtract KERNELBASE from a physical address.
Don't use __pa() in drivers. That's expected behavior. Why are
you doing that?

Desperation.

=20

quoted

quoted

You need something like the bigphys_remap patch for 2.4 that can be
found at ftp://source.mvista.com/pub/linuxppc/

I just checked the source, and that patch has indeed been applied.

=20
Ok, assuming it's all correct then I don't know why it does work
for you in your vendor tree. Have you asked Timesys for help?

Not yet.  I wanted to get some confidence that I was using the correct
APIs appropriately.

=20
Put some debug statements throughout fixup_bigphys_addr() to see
what's going on.

My include/asm/mmu.h has it defined as:
#ifndef CONFIG_440
#include <asm-generic/mmu.h>
#else
typedef unsigned long long phys_addr_t;
#define fixup_bigphys_addr(addr, size)   (addr)
#endif

I see that in later 2.4 kernels and in mainline 2.6 it is implemented
as an actual working routine.  Perhaps that explains it all.  The
ioremap() in my tree implements the fixup code inline, which would
explain why it works, right?

=20
-Matt
=20

Thanks again.
Ed