Subject: Modules broken on 2.2.1[02] on SA-1100 ?

From: "J.D. Bakker" <[email-masked]>
Date: Mon, 27 Sep 1999 22:04:01 +0200

Hi all,

[quick Q: is there any way to access physical memory locations,
specifically the GPIO registers, from userspace on SA-linux ? mmap(2) or
read(2) from either /dev/mem or /dev/kmem don't seem to work]

As per the subject. insmod on either 2.2.10-rmk2-np11 or 2.2.12-rmk1-np12
gives a very reproducible oops and a solid hang. I tried a home-compiled
insmod as well as the one from RedHat rawhide-arm4l; same results. I tried
the null module below as well as loop.o, dummy.o and ppp-deflate.o; no
change.

Platform:
LART board, SA-1100DA rev 9; 32M memory

Tools:
gcc version egcs-2.91.57 19980901 (egcs-1.1 release)
binutils 2.9.1.0.15

The module that I used:
/*
 * void.c
 * Dummy test driver.
 */

#include <linux/module.h>
#include <linux/init.h>

int __init init_module(void)
{
        printk(KERN_CRIT "Reached init_module.\n");
        return 0;
}

void cleanup_module(void)
{
        printk(KERN_CRIT "Reached cleanup_module.\n");
}

The result:

bash-2.01# insmod -V
insmod version 2.1.121
<snip usage for brevity>
bash-2.01# ./insmod dummy.o

bash-2.01# insmod void.o
Bad mode in prefetch abort handler detected: mode SVC_32
Vectors:
00000000: ef9f0000 ea0000a1 e59ff398 ea000093  ea000086 ea0000a9 ea000078
ea0000a6
00000020: 00000000 00000000 00000000 00000000  00000000 00000000 00000000
00000000
Stubs:
00000200: e59fd1a4 e24ee004 e58de000 e14fe000  e58de004 e3ced03f e38dd093
e169f00d
00000220: e20ee00f e28fd0b4 e79de10e e1b0f00e  e59fd17c e24ee008 e58de000
e14fe000
00000240: e58de004 e3ced03f e38dd093 e169f00d  e20ee00f e28fdf41 e79de10e
e1b0f00e
00000260: e59fd14c e24ee004 e58de000 e14fe000  e58de004 e3ced03f e38dd093
e169f00d
00000280: e21ee00f 059fe114 159fe114 e1b0f00e  e59fd118 e58de000 e14fe000
e58de004
000002a0: e3ced03f e38dd093 e169f00d e20ee00f  e28fd068 e79de10e e1b0f00e
e25ef004
000002c0: eafffffe 00000000 00000000 00000000  00000000 00000000 00000000
00000000
000002e0: c000f5e0 c000f388 c000f388 c000f4a0  c000f388 c000f388 c000f388
c000f388
00000300: c000f388 c000f388 c000f388 c000f388  c000f388 c000f388 c000f388
c000f388
00000320: c000f660 c000f39c c000f39c c000f520  c000f39c c000f39c c000f39c
c000f39c
00000340: c000f39c c000f39c c000f39c c000f39c  c000f39c c000f39c c000f39c
c000f39c
00000360: c000f580 c000f374 c000f374 c000f440  c000f374 c000f374 c000f374
c000f374
00000380: c000f374 c000f374 c000f374 c000f374  c000f374 c000f374 c000f374
c000f374
000003a0: c000f6e0 c000f360 c000f820 c00bf8d0  c00bf8dc c00bf8e8 00000000
00000000
000003c0: 00000000 00000000 00000000 00000000  00000000 00000000 00000000
00000000
000003e0: 00000000 00000000 00000000 00000000  00000000 00000000 00000000
00000000
00000400: 00000000 00000000 00000000 00000000  00000000 00000000 00000000
00000000
00000420: 00000000 00000000 00000000 00000000  00000000 00000000 00000000
00000000
00000440: 00000000 00000000 00000000 00000000  00000000 00000000 00000000
00000000
00000460: 00000000 00000000 00000000 00000000  00000000 00000000 00000000
00000000
00000480: 00000000 00000000 00000000 00000000  00000000 00000000 00000000
00000000
000004a0: 00000000 00000000 00000000 00000000  00000000 00000000

The oops, run through ksymoops:

Options used: -v ../../vmlinux (specified)
              -o ../../modules (specified)
              -K (specified)
              -L (specified)
              -m ../../System.map (specified)
              -c 1 (default)

No modules in ksyms, skipping objects
Reading Oops report from the terminal
Internal error: Oops: 0
CPU: 0
pc : [<c401ca64>]    lr : [<c2800060>]
sp : c1635ed4  ip : c1635f2c  fp : c1635f28
r10: 400fea44  r9 : ffffffea  r8 : c2800048
r7 : c28000c8  r6 : 00000000  r5 : c2800000  r4 : 00000000
r3 : c280004c  r2 : c00f6350  r1 : c00e5000  r0 : c2800088
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: C07B917F  Table: C07B917F  DAC: 00000015
Process insmod (pid: 27, stackpage=c1635000)
Stack:
c1635f00:                            c2800060  c401ca64 a0000013 ffffffff
c1635fb0
c1635f20: c1635f2c c001ff48 c2800058 00000004  c2800048 c1635f3c c2800048
c06e0000
c1635f40: c06e2000 00000048 c00c0e44 c2800048  000000c8 00000000 00000000
00000000
c1635f60: 00000000 00000000 00000000 00000000  00000000 00000000 00000000
00000000
c1635f80: 00000000 00000000 00000000 020113e0  c000f908 00000080 c1634000
c1635ff4
c1635fa0: 00000000 00000000 c1635fb4 c000f760  c001f958 020113e0 020113e0
02017d90
c1635fc0: 00000000 00000000 020113e0 00000002  02000a24 02008260 0200472c
00000000
c1635fe0: 400fea44 bffffe38 02017d90 bffffd40  020046bc 02007ee8 60000010
020113e0
Backtrace:
Function entered at [<c280004c>] from [<c001ff48>]
Function entered at [<c001f94c>] from [<c000f760>]
  r9 = 00000000
  r8 = c1635ff4
  r7 = c1634000
  r6 = 00000080
  r5 = c000f908
  r4 = 020113e0
Code: pc not in code space
Warning, Code line not seen, dumping what data is available

>>EIP: c401ca64 <END_OF_CODE+3f3ace8/????>
Trace: c280004c <END_OF_CODE+271e2d0/????>
Trace: c001ff48 <L0+14/18>
Trace: c001f94c <sys_init_module+0/0>
Trace: c000f760 <fast_syscall_return+0/4>

1 warning issued.  Results may not be reliable.

Any ideas ?

JDB

--
Jan-Derk Bakker, [email-masked]

The lazy man's proverb:
    'There's no business like slow business !'

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Mon, 27 Sep 1999 21:44:27 +0100

>read(2) from either /dev/mem or /dev/kmem don't seem to work]

Mmap'ing /dev/mem ought to give you access to physical memory and is 
probably the right way to do this.  I can't think of any reason why it 
shouldn't work on the SA-1100 offhand.

>gcc version egcs-2.91.57 19980901 (egcs-1.1 release)

What version of modutils?

>sp : c1635ed4  ip : c1635f2c  fp : c1635f28

My best guess is that something is going wrong with the code that resolves 
branches when the module is loaded.

p.

---

From: "J.D. Bakker" <[email-masked]>
Date: Mon, 27 Sep 1999 23:41:28 +0200

>shouldn't work on the SA-1100 offhand.

Theory: The SA-1100 doesn't like cache line reads from the internal control
registers.

I wrote a small app[1] that memmaps a page and tries to read the first
longword. It works as expected for all areas *except* the space between
0x8000 0000 and 0xBFFF FFFF. That's where the internal control registers of
the SA live; if I point my app there, the mmap(2) will succeed but reading
the data invariably yields

Internal error: External abort on linefetch: 6

My guess is that the memory is mapped cacheable, and the SA is allergic to
the ensuing line fills.

A) Does this sound plausible ?
B) Is there a way to fix this ?

>What version of modutils?

2.1.121.

>branches when the module is loaded.

Anything I can do to fix/resolve that ?

JDB.

[1] Simple mmapper:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <signal.h>
#include <fcntl.h>
#include <termios.h>
#include <sys/types.h>
#include <sys/mman.h>

#define FATAL do { fprintf(stderr, "Error at line %d, file %s (%d) [%s]\n", \
  __LINE__, __FILE__, errno, strerror(errno)); exit(1); } while(0)

#define MAP_SIZE 4096

int main(int argc, char **argv) {
    int fd;
    unsigned long *addr;
	off_t target = 0xE0000000;

	if(argc > 1)
		target = strtol(argv[1], 0, 0) & 0xFFFFF000;

    if((fd = open("/dev/mem", O_RDWR)) == -1) FATAL;
    printf("/dev/mem opened.\n"); fflush(stdout);

    /* Map one page of the always-zero memory */
    addr = (unsigned long *) mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE,
MAP_SHARED, fd, target);
    if(addr == (unsigned long *) -1) FATAL;
    printf("Memory mapped at address %p.\n", addr); fflush(stdout);
    printf("Value at address 0x%X (%p): 0x%X\n", target, addr, *addr);
fflush(stdout);

	if(munmap(addr, MAP_SIZE) == -1) FATAL;
    close(fd);
    return 0;
}

The lazy man's proverb:

---

From: [email-masked]
Date: Mon, 27 Sep 1999 23:04:29 +0100 (BST)

J.D. Bakker writes:
> >This is the classic modutils-can't-handle-system-memory-over-32MB syndrome,
> >seen many times on RiscPCs.  I don't think it's compiler related - it's
> >modutils-related.
> 
> My memory is *exactly* 32M; would it be useful to test it tomorrow with
> only one bank (16M) ?

It will more than likely work with 16M, and 24M (the bug in the 2.0 modutils
went undiscovered for some time until I updated my RiscPC to have 40MB).
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: "J.D. Bakker" <[email-masked]>
Date: Mon, 27 Sep 1999 23:57:03 +0200

>Theory: The SA-1100 doesn't like cache line reads from the internal control

Scratch that. The program was buggy; should have used strtoul instead. I
can't check it thoroughly now, but it seems to work. Sorry for the wild
goose chase.

JDB.

Note to self: Don't bother people with theories developed 5mins before the
building closes.

The lazy man's proverb:

---

From: [email-masked]
Date: Mon, 27 Sep 1999 22:49:47 +0100 (BST)

I thought that this was fixed ages ago (even before modutils 2.1.121 was
out).
   _____

---

From: "J.D. Bakker" <[email-masked]>
Date: Mon, 27 Sep 1999 23:58:35 +0200

JDB
[who has to run now, don't want to be locked in...]

The lazy man's proverb:

---

From: "J.D. Bakker" <[email-masked]>
Date: Tue, 28 Sep 1999 11:46:47 +0200

>went undiscovered for some time until I updated my RiscPC to have 40MB).

Checked it with 16M; you're right, it works. Do you know how to fix this,
or where I could get a working insmod binary ?

How do the NetWinder folks handle this, BTW ? ISTR that their smallest
model has 32M, and they do use modules.

JDB
[16M with an 8M ramdisk, a kernel and no swap makes me feel a bit...
claustrophobic. And yes, Nico, I know it can be a *lot* tighter..]

--
"There is a style of design I call "wishful thinking engineering."  It starts
 with something like "pigs can fly if you feed them enough beans" and develops
 utopian plans such as like having everyone commute to work riding on personal
 pigs, and along the way ignores minor details such as the consequent rain of
 the non-gaseous byproducts."

 (Vernon Schryver in n.a.n-a.e)

---

From: Philip Blundell <[email-masked]>
Date: Tue, 28 Sep 1999 10:54:29 +0100

>I thought that this was fixed ages ago (even before modutils 2.1.121 was

Yeah, I did too but maybe an old version escaped somehow.  Get the latest from 
ftp://ftp.ocs.com.au/pub/modutils and see if it helps, I guess.

p.

---

From: Philip Blundell <[email-masked]>
Date: Tue, 28 Sep 1999 11:27:17 +0100

>model has 32M, and they do use modules.

Yeah.  I guess they use a working insmod. :-)

p.

---

From: "J.D. Bakker" <[email-masked]>
Date: Tue, 28 Sep 1999 14:00:54 +0200

>ftp://ftp.ocs.com.au/pub/modutils and see if it helps, I guess.

That did the trick. Thanks a lot !

JDB.

--
"A satisfied customer ? We ought to have him stuffed !"
    -- Basil Fawlty