mmap question on ppc440

mmap question on ppc440

[Steven A. Falco]

I am attempting to access the CPLD on the AMCC Sequoia board from 
user-land.  I open /dev/mem, and mmap it, then try to access the 
resulting pointer.  That works fine when accessing physical addresses 
that correspond to RAM, but as soon as I try to access the CPLD at 
physical address 0xc0000000, I get an infinite machine check.

I've done this successfully on the ARM architecture, and I've found 
examples where people do this on PPC, so I would expect this to work.

Here are a few successful reads:

bash-3.00# ./mm -r -a 0
paddr 00000000, map_base 0x30018000
00000000: c0348200

bash-3.00# ./mm -r -a 100
paddr 00000000, map_base 0x30018100
00000100: 7c0004ac

And here is the machine check:

bash-3.00# ./mm -r -a c0000000
paddr c0000000, Machine check in kernel mode.
Machine check in kernel mode.
Machine check in kernel mode.
Machine check in kernel mode.

My code looks like this (I'll post the whole program if anybody wants to 
see it:

        if((fd = open("/dev/mem", O_RDWR | O_SYNC)) == -1) {
                fprintf(stderr, "cannot open\n");
                exit(1);
        }
        offset = addr & MAP_MASK;
        paddr = addr & ~MAP_MASK;
        map_base = (unsigned long *)mmap(NULL, MAP_SIZE,
                        PROT_READ | PROT_WRITE, MAP_SHARED, fd, paddr);

Is it possible to access devices like this from user-land?  If so, what 
am I doing wrong?

    Thanks,
    Steve

Re: mmap question on ppc440

[Josh Boyer]

On Mon, 05 Nov 2007 16:02:59 -0500
"Steven A. Falco" <sfalco@harris.com> wrote:

> I am attempting to access the CPLD on the AMCC Sequoia board from 
> user-land.  I open /dev/mem, and mmap it, then try to access the 
> resulting pointer.  That works fine when accessing physical addresses 
> that correspond to RAM, but as soon as I try to access the CPLD at 
> physical address 0xc0000000, I get an infinite machine check.

That's because the CPLD is actually at physical address 0x1C0000000.
Yay for 36-bit physical addresses.

josh

Re: mmap question on ppc440

[Stefan Roese]

On Monday 05 November 2007, Josh Boyer wrote:
> > I am attempting to access the CPLD on the AMCC Sequoia board from
> > user-land.  I open /dev/mem, and mmap it, then try to access the
> > resulting pointer.  That works fine when accessing physical addresses
> > that correspond to RAM, but as soon as I try to access the CPLD at
> > physical address 0xc0000000, I get an infinite machine check.
>
> That's because the CPLD is actually at physical address 0x1C0000000.
> Yay for 36-bit physical addresses.

Right. Are you using arch/ppc or arch/powerpc? If it's arch/ppc you could
give the following patch a try:

@@ -275,6 +275,14 @@
 {
        size_t size = vma->vm_end - vma->vm_start;

+#if defined(CONFIG_44x) && !defined(CONFIG_PPC_MERGE)
+       /*
+        * 2006-08-07: sr
+        * Needed on 44x-er systems for 36bit addresses (like pci on 440gx)
+        */
+       vma->vm_pgoff = (fixup_bigphys_addr(vma->vm_pgoff << PAGE_SHIFT, size) >> PAGE_SHIFT);
+#endif
+
        if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size))
                return -EINVAL;


Best regards,
Stefan

Re: mmap question on ppc440

[Benjamin Herrenschmidt]

On Tue, 2007-11-06 at 07:50 +0100, Stefan Roese wrote:
> On Monday 05 November 2007, Josh Boyer wrote:
> > > I am attempting to access the CPLD on the AMCC Sequoia board from
> > > user-land.  I open /dev/mem, and mmap it, then try to access the
> > > resulting pointer.  That works fine when accessing physical addresses
> > > that correspond to RAM, but as soon as I try to access the CPLD at
> > > physical address 0xc0000000, I get an infinite machine check.
> >
> > That's because the CPLD is actually at physical address 0x1C0000000.
> > Yay for 36-bit physical addresses.
> 
> Right. Are you using arch/ppc or arch/powerpc? If it's arch/ppc you could
> give the following patch a try:
> 
> @@ -275,6 +275,14 @@
>  {
>         size_t size = vma->vm_end - vma->vm_start;
> 
> +#if defined(CONFIG_44x) && !defined(CONFIG_PPC_MERGE)
> +       /*
> +        * 2006-08-07: sr
> +        * Needed on 44x-er systems for 36bit addresses (like pci on 440gx)
> +        */
> +       vma->vm_pgoff = (fixup_bigphys_addr(vma->vm_pgoff << PAGE_SHIFT, size) >> PAGE_SHIFT);
> +#endif
> +
>         if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size))
>                 return -EINVAL;

I think we need to ditch the bigphys fixup stuff and come up with a way
to make /dev/mem work with the actual 36 bits offsets (after all, it's
all pgoff, it should work).

The other problem is X of course... 32 bits X server currently cannot
cope with physical addresses > 32 bits at all. They will just blow up or
randomly scribble over /dev/mem.

The solution is libpciaccess and the new pci-rework branch of X which
uses it, but I haven't had a chance to test that properly yet on 4xx.

Ben.

Re: mmap question on ppc440

[Josh Boyer]

On Wed, 07 Nov 2007 09:02:10 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> On Tue, 2007-11-06 at 07:50 +0100, Stefan Roese wrote:
> > On Monday 05 November 2007, Josh Boyer wrote:
> > > > I am attempting to access the CPLD on the AMCC Sequoia board from
> > > > user-land.  I open /dev/mem, and mmap it, then try to access the
> > > > resulting pointer.  That works fine when accessing physical addresses
> > > > that correspond to RAM, but as soon as I try to access the CPLD at
> > > > physical address 0xc0000000, I get an infinite machine check.
> > >
> > > That's because the CPLD is actually at physical address 0x1C0000000.
> > > Yay for 36-bit physical addresses.
> > 
> > Right. Are you using arch/ppc or arch/powerpc? If it's arch/ppc you could
> > give the following patch a try:
> > 
> > @@ -275,6 +275,14 @@
> >  {
> >         size_t size = vma->vm_end - vma->vm_start;
> > 
> > +#if defined(CONFIG_44x) && !defined(CONFIG_PPC_MERGE)
> > +       /*
> > +        * 2006-08-07: sr
> > +        * Needed on 44x-er systems for 36bit addresses (like pci on 440gx)
> > +        */
> > +       vma->vm_pgoff = (fixup_bigphys_addr(vma->vm_pgoff << PAGE_SHIFT, size) >> PAGE_SHIFT);
> > +#endif
> > +
> >         if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size))
> >                 return -EINVAL;
> 
> I think we need to ditch the bigphys fixup stuff and come up with a way
> to make /dev/mem work with the actual 36 bits offsets (after all, it's
> all pgoff, it should work).

We did ditch bigphys in arch/powerpc.  mmap64 works apparently.

> The other problem is X of course... 32 bits X server currently cannot
> cope with physical addresses > 32 bits at all. They will just blow up or
> randomly scribble over /dev/mem.
> 
> The solution is libpciaccess and the new pci-rework branch of X which
> uses it, but I haven't had a chance to test that properly yet on 4xx.

Um... because arch/powerpc 4xx doesn't have PCI support? :)  You and
Valentine and Vitaly keep trading emails about it though, which is a
good sign.

josh

Re: mmap question on ppc440

[Benjamin Herrenschmidt]

> > The solution is libpciaccess and the new pci-rework branch of X which
> > uses it, but I haven't had a chance to test that properly yet on 4xx.
> 
> Um... because arch/powerpc 4xx doesn't have PCI support? :)  You and
> Valentine and Vitaly keep trading emails about it though, which is a
> good sign.

Yeah :-) It shouldn't be hard in fact.

Ben.