mmap on 440gx

[Matt Porter]

On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote:
> On 6/16/05, Matt Porter <mporter at kernel.crashing.org> wrote:
> > On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote:
> 
> Thanks for taking the time to reply.
> 
> > > 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.
> > 
> > > 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?
 
> > 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