Skip to contentSkip to conversation

mmap question on ppc440

DISCUSSION Steven A. Falco 4 participants 6 messages Nov 5, 2007 – Nov 6, 2007

lore
Share & tools
lore

Steven A. Falco

author
#0 lore raw

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

#1 lore raw
Quoted 5 lines · On Mon, 05 Nov 2007 16:02:59 -0500 "Steven A. Falco" <[email protected]> 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

#2 lore raw
Quoted 8 lines · Josh Boyer
Quoted 5 lines

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

#3 lore raw
Quoted 17 lines · Stefan Roese
Quoted 8 lines · Josh Boyer
Quoted 5 lines

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:

(quoted diff) +0 -0
@@ -275,6 +275,14 @@
 {
        size_t size = vma->vm_end - vma->vm_start;

Review line 287

Quoted 10 lines
(quoted diff) +8 -0
+#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.

#4 lore raw
Quoted 19 lines · On Wed, 07 Nov 2007 09:02:10 +1100 Benjamin Herrenschmidt…
Quoted 17 lines · Stefan Roese
Quoted 8 lines · Josh Boyer
Quoted 5 lines

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:

(quoted diff) +0 -0
@@ -275,6 +275,14 @@
 {
        size_t size = vma->vm_end - vma->vm_start;
Quoted 14 lines

Review line 287

Quoted 10 lines
(quoted diff) +8 -0
+#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.

Quoted 6 lines

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

#5 lore raw
Quoted 7 lines
Quoted 3 lines

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.