* PPC arch and spinlocks
From: Garcia Jérémie @ 2005-06-08 14:29 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody, I need your help one more time.
I'm new to kernel device driver (linux newbie) and I'd like to control =
concurrent access
to our hardware resources. (I'm working on a ppc405EP platform =
uniprocessor)
Reading the Allessandro Rubini book (Linux device drivers) and many =
lists and guides on the web,
I concluded that spinlocks were very adapted to my expectations.
So, I decided to declare a spinlock in my module and offer, via ioctl, =
the possibilty to user
space programs to handle it with spin_trylock(), spin_lock() and =
spin_unlock().
Unfortunately I saw that was not working properly and so, I wanted to =
debug the "spinlock-process"
printing the value of it after calling one of the above routine:=20
spinlock_t my_spinlock =3D SPIN_UNLOCKED;
[...]
spin_try_lock(&my_spinlock);
printk("value: %d\n",my_spinlock.lock);
[...]
At compile time, I had an error that told me no "lock" member for this =
type of structure.
And it was write, cause I investigated and noticed that the definition =
used for "spinlock_t"=20
structure was the following in <linux/spinlock.h>:
#if (__GNUC__ > 2 || __GNUC_MINOR__ > 95) =20
typedef struct { } spinlock_t;
#define SPIN_LOCK_UNLOCKED (spinlock_t) { } // empty structure...
[...]
I don't understand cause I thought that spinlocks were recommended for =
SMP platforms but could be
safely used in uni-processor platforms too.=20
So did I miss something to be able to use them (in config?? is it =
specific to PPC arch??)?
If not, is there a way to get a similar behavior with others technics =
(mutex??). I saw Posix mutex? Are they
usable in kernel mode?
I really need to have an equivalent of the spin_trylock() routine in =
order not to have the processus waiting till
the semaphore is available when tryin to get it. (ask and take if =
available, but not sleep).
Please give me some tips.
Tks a lot for your precious help!!
Jeremie
^ permalink raw reply
* Re: [UPDATE] Getting ownership for various boards/platforms configs
From: Kumar Gala @ 2005-06-08 14:36 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev list, Linux PPC Embedded list
In-Reply-To: <20050608092453.GA11455@iram.es>
Gabriel,
Agreed, but the question on the table is ownership of the current code.
- kumar
On Jun 8, 2005, at 4:24 AM, Gabriel Paubert wrote:
> On Tue, Jun 07, 2005 at 04:47:35PM -0500, Kumar Gala wrote:
>> The following boards have no owners and if they dont get one the plan
>> is to kill them:
>>
>> ep405
>> mvme5100
>> pcore
>
> Actually mvme5100 and pplus could easily be merged with generic
> PreP IIRC. At least I wrote a bootloader that remapped my
> MVME2400/2600/2700 to look like an MVME5100 (CHRP memory map
> but residual data and no OF). This allows much larger
> windows to map to the VME bus (which is often very
> sparsely populated).
>
> The only real difference at boot between MVME5100 and
> pplus is the mapping of physical addresses to PCI
> I/O and memory space, and perhaps also the way to access
> the console device. But I don't have any MVME5100 nor
> do I plan do buy one (perhaps an MVME6100 but the host
> bridge is completely different).
>
> The question is whether we want a residual data to
> pseudo OF device-tree translator in the bootloader
> or another way of passing board data to the kernel.
>
> Gabriel
^ permalink raw reply
* Re: MPC8272 runs application with segmentation fault
From: Nai-Hsien @ 2005-06-08 14:51 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <746d2388bf461a77b5dd0b25f3250d81@freescale.com>
Kumar,
I got the kernel from Montavista version 3.1, which uses Linux kernel
2.4.20.
According to readelf, my libc is version 2.3.2, which is also from
Montavista.
In cputable.c, I already added following entry for MPC8272.
{ /* 827x, 828x (8270, 8275, 8280, 8272 are all 603e cores) */
0x7fff0000, 0x00820000, "827x & 828x",
CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB,
COMMON_PPC,
256, 256,
__setup_cpu_603
},
Regards
Dennis
----- Original Message -----
From: "Kumar Gala" <kumar.gala@freescale.com>
To: "Nai-Hsien" <dennis@loop.com.tw>
Cc: <linuxppc-embedded@ozlabs.org>; "Andrew Williams" <awilliam@nortel.com>
Sent: Wednesday, June 08, 2005 9:52 PM
Subject: Re: MPC8272 runs application with segmentation fault
> A few questions, where did you get the kernel for the 8272 you are
> using? Can you report back what libc version you are running with.
> Also, can see what entry in arch/ppc/kernel/cputable.c has a pvr_value
> of 0x00820000 and report that back as well.
>
> - kumar
>
> On Jun 8, 2005, at 8:39 AM, Nai-Hsien wrote:
>
> > Andrew,
> > I believe I already modify my u-boot to detect the processor.
> >
> > If I statically link my program, I find that the program can run
> > on my MPC8272 platform properly, so I think maybe the problem
> > is caused by shared library. However, the same file system (of course,
> > same shared library) can run on my MPC8245 platform.
> >
> > With the observation, I think my kernel is not handling shared library
> > properly. Is there any part of the kernel I should check?
> >
> > I added some code in do_page_fault() to dump some information, shown
> > as below, when my program get problem.
> >
> > PID=34(console): Trap=300, NIP=0x0ffc6d90, LR=0x0ffc6d20, VM:
> > (start=0x30000000,
> > end=0x30017000, flags=0x00000875), addr=0x2e313056
> > Segmentation fault
> >
> > Thank you
> > Dennis
> >
> >
> > ----- Original Message -----
> > From: Andrew <mailto:awilliam@nortel.com> Williams
> > To: Nai-Hsien <mailto:dennis@loop.com.tw> ;
> > linuxppc-embedded@ozlabs.org
> > Sent: Tuesday, June 07, 2005 10:17 PM
> > Subject: RE: MPC8272 runs application with segmentation fault
> >
> > Take a alook at the checkcpu() routine in /cpu/mpc8260/cpu.c .
> > Validate that your CPU is correctly being identified, and thus
> > initialized.
> > We had identical symptoms with the 8270.
> >
> > We added the following after the case for the PVR_8260_HIP7:
> >
> > case PVR_8280a_HIP7:
> > case PVR_8280_HIP7:
> > k = 7;
> > printf (CPU_ID_STR " (HiP%d Rev %02x, Mask ", k, rev);
> > break;
> >
> > include/asm-ppc/processor.h
> >
> > #define PVR_8280_HIP7 0x80822013
> > #define PVR_8280a_HIP7 0x80822014
> >
> > A.
> >
> > -----Original Message-----
> > From: linuxppc-embedded-bounces@ozlabs.org
> > [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Nai-Hsien
> > Sent: June 7, 2005 9:11 AM
> > To: linuxppc-embedded@ozlabs.org
> > Subject: MPC8272 runs application with segmentation fault
> >
> >
> > Dear experts,
> >
> > I have two hardware boards, one uses MPC8245 and the other one uses
> > MPC8272.
> > Initially, I use the MPC8245 board to port Linux 2.4.20 and write some
> > applications.
> > I already do a lot of test on the MPC8245 board and all my application
> > programs work
> > fine.
> >
> > After this, I use the same kernel configuration and same file system
> > that are being used
> > by the MPC8245 board to port the whole system to my MPC8272.
> > Now, I can boot the kernel and run busybox well. However, when
> > I run my application programs, I always get segmentation fault.
> > Following is a strace
> > dump. Could anybody give me some idea?
> >
> > Thank you
> > Dennis
> >
> > ====================================================
> > execve("sbin/console", ["sbin/console"], [/* 6 vars */]) = 0
> > uname({sys="Linux", node="6200_linux", ...}) = 0
> > brk(0) = 0x10059134
> > open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
> > directory)
> > open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or
> > directory)
> > open("/lib/libncurses.so.5", O_RDONLY) = 3
> > read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\001"...,
> > 1024) = 1024
> > fstat64(0x3, 0x7ffff098) = 0
> > mmap(0xff97000, 362628, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> > 0xff97000
> > mprotect(0xffd4000, 112772, PROT_NONE) = 0
> > mmap(0xffd7000, 86016, PROT_READ|PROT_WRITE|PROT_EXEC,
> > MAP_PRIVATE|MAP_FIXED, 3, 0x30000) = 0xffd7000
> > mmap(0xffec000, 14468, PROT_READ|PROT_WRITE|PROT_EXEC,
> > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffec000
> > close(3) = 0
> > open("/lib/libdl.so.2", O_RDONLY) = 3
> > read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\34"...,
> > 1024) = 1024
> > fstat64(0x3, 0x7ffff078) = 0
> > mmap(0xff74000, 74812, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> > 0xff74000
> > mprotect(0xff77000, 62524, PROT_NONE) = 0
> > mmap(0xff84000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC,
> > MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xff84000
> > close(3) = 0
> > open("/lib/libnsl.so.1", O_RDONLY) = 3
> > read(3,
> > "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0A\274"..., 1024)
> > = 1024
> > fstat64(0x3, 0x7ffff058) = 0
> > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> > 0) = 0x30017000
> > mmap(0xff3e000, 152068, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> > 0xff3e000
> > mprotect(0xff51000, 74244, PROT_NONE) = 0
> > mmap(0xff5e000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC,
> > MAP_PRIVATE|MAP_FIXED, 3, 0x10000) = 0xff5e000
> > mmap(0xff61000, 8708, PROT_READ|PROT_WRITE|PROT_EXEC,
> > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xff61000
> > close(3) = 0
> > open("/lib/libc.so.6", O_RDONLY) = 3
> > read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\322"...,
> > 1024) = 1024
> > fstat64(0x3, 0x7ffff038) = 0
> > mmap(0xfddd000, 1379388, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> > 0xfddd000
> > mprotect(0xff16000, 97340, PROT_NONE) = 0
> > mmap(0xff1d000, 61440, PROT_READ|PROT_WRITE|PROT_EXEC,
> > MAP_PRIVATE|MAP_FIXED, 3, 0x130000) = 0xff1d000
> > mmap(0xff2c000, 7228, PROT_READ|PROT_WRITE|PROT_EXEC,
> > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xff2c000
> > close(3) = 0
> > brk(0) = 0x10059134
> > brk(0x1005a134) = 0x1005a134
> > brk(0x1005b000) = 0x1005b000
> > write(2, "before init_ncurses()\n", 22) = 22
> > write(2, "before initscr()\n", 17) = 17
> > access("/usr/share/terminfo/v/vt100", R_OK) = 0
> > open("/usr/share/terminfo/v/vt100", O_RDONLY) = 3
> > read(3, "\32\1,\0\25\0\7\0\16\1\3\2", 12) = 12
> > read(3, "vt100|vt100-am|dec vt100 (w/adva"..., 44) = 44
> > read(3, "\0\1\0\0\1\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\1", 21) = 21
> > read(3, "\0", 1) = 1
> > read(3, "P\0\10\0\30\0\377\377\377\377\377\377\3\0", 14) = 14
> > read(3, "\377\377\0\0\2\0\4\0\25\0\32\0&\0.\0\377\377\377\3777\0"...,
> > 540) = 540
> > read(3, "\7\0\r\0\33[%i%p1%d;%p2%dr\0\33[3g\0\33[H\33[J"..., 515) = 515
> > read(3, "", 1) = 0
> > read(3, "", 10) = 0
> > close(3) = 0
> > -- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > +++ killed by SIGSEGV +++
> > Segmentation fault
> >
> >
> >
> > <ATT169162.txt>
>
>
^ permalink raw reply
* Re: MPC8272 runs application with segmentation fault
From: Kumar Gala @ 2005-06-08 14:59 UTC (permalink / raw)
To: Nai-Hsien; +Cc: linuxppc-embedded
In-Reply-To: <010f01c56c39$9d5a8ca0$0102000a@loop.com.tw>
On Jun 8, 2005, at 9:51 AM, Nai-Hsien wrote:
> Kumar,
> I got the kernel from Montavista version 3.1, which uses Linux kernel
> 2.4.20.
> According to readelf, my libc is version 2.3.2, which is also from
> Montavista.
There is your problem, change the 256, 256 in this entry to 32, 32.
> In cputable.c, I already added following entry for MPC8272.
>
> { /* 827x, 828x (8270, 8275, 8280, 8272 are all 603e cores) */
> 0x7fff0000, 0x00820000, "827x & 828x",
> CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB,
> COMMON_PPC,
> 256, 256,
> __setup_cpu_603
> },
- kumar
> ----- Original Message -----
> From: "Kumar Gala" <kumar.gala@freescale.com>
> To: "Nai-Hsien" <dennis@loop.com.tw>
> Cc: <linuxppc-embedded@ozlabs.org>; "Andrew Williams"
> <awilliam@nortel.com>
> Sent: Wednesday, June 08, 2005 9:52 PM
> Subject: Re: MPC8272 runs application with segmentation fault
>
>
>> A few questions, where did you get the kernel for the 8272 you are
>> using? Can you report back what libc version you are running with.
>> Also, can see what entry in arch/ppc/kernel/cputable.c has a pvr_value
>> of 0x00820000 and report that back as well.
>>
>> - kumar
>>
>> On Jun 8, 2005, at 8:39 AM, Nai-Hsien wrote:
>>
>>> Andrew,
>>> I believe I already modify my u-boot to detect the processor.
>>>
>>> If I statically link my program, I find that the program can run
>>> on my MPC8272 platform properly, so I think maybe the problem
>>> is caused by shared library. However, the same file system (of
>>> course,
>>> same shared library) can run on my MPC8245 platform.
>>>
>>> With the observation, I think my kernel is not handling shared
>>> library
>>> properly. Is there any part of the kernel I should check?
>>>
>>> I added some code in do_page_fault() to dump some information, shown
>>> as below, when my program get problem.
>>>
>>> PID=34(console): Trap=300, NIP=0x0ffc6d90, LR=0x0ffc6d20, VM:
>>> (start=0x30000000,
>>> end=0x30017000, flags=0x00000875), addr=0x2e313056
>>> Segmentation fault
>>>
>>> Thank you
>>> Dennis
>>>
>>>
>>> ----- Original Message -----
>>> From: Andrew <mailto:awilliam@nortel.com> Williams
>>> To: Nai-Hsien <mailto:dennis@loop.com.tw> ;
>>> linuxppc-embedded@ozlabs.org
>>> Sent: Tuesday, June 07, 2005 10:17 PM
>>> Subject: RE: MPC8272 runs application with segmentation fault
>>>
>>> Take a alook at the checkcpu() routine in /cpu/mpc8260/cpu.c .
>>> Validate that your CPU is correctly being identified, and thus
>>> initialized.
>>> We had identical symptoms with the 8270.
>>>
>>> We added the following after the case for the PVR_8260_HIP7:
>>>
>>> case PVR_8280a_HIP7:
>>> case PVR_8280_HIP7:
>>> k = 7;
>>> printf (CPU_ID_STR " (HiP%d Rev %02x, Mask ", k,
>>> rev);
>>> break;
>>>
>>> include/asm-ppc/processor.h
>>>
>>> #define PVR_8280_HIP7 0x80822013
>>> #define PVR_8280a_HIP7 0x80822014
>>>
>>> A.
>>>
>>> -----Original Message-----
>>> From: linuxppc-embedded-bounces@ozlabs.org
>>> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Nai-Hsien
>>> Sent: June 7, 2005 9:11 AM
>>> To: linuxppc-embedded@ozlabs.org
>>> Subject: MPC8272 runs application with segmentation fault
>>>
>>>
>>> Dear experts,
>>>
>>> I have two hardware boards, one uses MPC8245 and the other one uses
>>> MPC8272.
>>> Initially, I use the MPC8245 board to port Linux 2.4.20 and write
>>> some
>>> applications.
>>> I already do a lot of test on the MPC8245 board and all my
>>> application
>>> programs work
>>> fine.
>>>
>>> After this, I use the same kernel configuration and same file system
>>> that are being used
>>> by the MPC8245 board to port the whole system to my MPC8272.
>>> Now, I can boot the kernel and run busybox well. However, when
>>> I run my application programs, I always get segmentation fault.
>>> Following is a strace
>>> dump. Could anybody give me some idea?
>>>
>>> Thank you
>>> Dennis
>>>
>>> ====================================================
>>> execve("sbin/console", ["sbin/console"], [/* 6 vars */]) = 0
>>> uname({sys="Linux", node="6200_linux", ...}) = 0
>>> brk(0) = 0x10059134
>>> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
>>> directory)
>>> open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or
>>> directory)
>>> open("/lib/libncurses.so.5", O_RDONLY) = 3
>>> read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\001"...,
>>> 1024) = 1024
>>> fstat64(0x3, 0x7ffff098) = 0
>>> mmap(0xff97000, 362628, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>>> 0xff97000
>>> mprotect(0xffd4000, 112772, PROT_NONE) = 0
>>> mmap(0xffd7000, 86016, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_FIXED, 3, 0x30000) = 0xffd7000
>>> mmap(0xffec000, 14468, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffec000
>>> close(3) = 0
>>> open("/lib/libdl.so.2", O_RDONLY) = 3
>>> read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\34"...,
>>> 1024) = 1024
>>> fstat64(0x3, 0x7ffff078) = 0
>>> mmap(0xff74000, 74812, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>>> 0xff74000
>>> mprotect(0xff77000, 62524, PROT_NONE) = 0
>>> mmap(0xff84000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xff84000
>>> close(3) = 0
>>> open("/lib/libnsl.so.1", O_RDONLY) = 3
>>> read(3,
>>> "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0A\274"..., 1024)
>>> = 1024
>>> fstat64(0x3, 0x7ffff058) = 0
>>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
>>> 0) = 0x30017000
>>> mmap(0xff3e000, 152068, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>>> 0xff3e000
>>> mprotect(0xff51000, 74244, PROT_NONE) = 0
>>> mmap(0xff5e000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_FIXED, 3, 0x10000) = 0xff5e000
>>> mmap(0xff61000, 8708, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xff61000
>>> close(3) = 0
>>> open("/lib/libc.so.6", O_RDONLY) = 3
>>> read(3,
>>> "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\322"...,
>>> 1024) = 1024
>>> fstat64(0x3, 0x7ffff038) = 0
>>> mmap(0xfddd000, 1379388, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>>> 0xfddd000
>>> mprotect(0xff16000, 97340, PROT_NONE) = 0
>>> mmap(0xff1d000, 61440, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_FIXED, 3, 0x130000) = 0xff1d000
>>> mmap(0xff2c000, 7228, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xff2c000
>>> close(3) = 0
>>> brk(0) = 0x10059134
>>> brk(0x1005a134) = 0x1005a134
>>> brk(0x1005b000) = 0x1005b000
>>> write(2, "before init_ncurses()\n", 22) = 22
>>> write(2, "before initscr()\n", 17) = 17
>>> access("/usr/share/terminfo/v/vt100", R_OK) = 0
>>> open("/usr/share/terminfo/v/vt100", O_RDONLY) = 3
>>> read(3, "\32\1,\0\25\0\7\0\16\1\3\2", 12) = 12
>>> read(3, "vt100|vt100-am|dec vt100 (w/adva"..., 44) = 44
>>> read(3, "\0\1\0\0\1\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\1", 21) = 21
>>> read(3, "\0", 1) = 1
>>> read(3, "P\0\10\0\30\0\377\377\377\377\377\377\3\0", 14) = 14
>>> read(3, "\377\377\0\0\2\0\4\0\25\0\32\0&\0.\0\377\377\377\3777\0"...,
>>> 540) = 540
>>> read(3, "\7\0\r\0\33[%i%p1%d;%p2%dr\0\33[3g\0\33[H\33[J"..., 515) =
>>> 515
>>> read(3, "", 1) = 0
>>> read(3, "", 10) = 0
>>> close(3) = 0
>>> -- SIGSEGV (Segmentation fault) @ 0 (0) ---
>>> +++ killed by SIGSEGV +++
>>> Segmentation fault
>>>
>>>
>>>
>>> <ATT169162.txt>
>>
>>
^ permalink raw reply
* Re: MPC8272 runs application with segmentation fault
From: Nai-Hsien @ 2005-06-08 15:02 UTC (permalink / raw)
To: Kumar Gala, linuxppc-embedded, Andrew Williams
Kumar and Andrew,
When I were re-checking the previous mail, I find a mistake about cache line
size.
Now, I can run my program on the MPC8272. (I changed the line size for 256
to 32.)
Thanks a lot for your help.
Dennis
----- Original Message -----
From: "Nai-Hsien" <dennis@loop.com.tw>
To: "Kumar Gala" <kumar.gala@freescale.com>
Cc: <linuxppc-embedded@ozlabs.org>; "Andrew Williams" <awilliam@nortel.com>
Sent: Wednesday, June 08, 2005 10:51 PM
Subject: Re: MPC8272 runs application with segmentation fault
> Kumar,
> I got the kernel from Montavista version 3.1, which uses Linux kernel
> 2.4.20.
> According to readelf, my libc is version 2.3.2, which is also from
> Montavista.
>
> In cputable.c, I already added following entry for MPC8272.
>
> { /* 827x, 828x (8270, 8275, 8280, 8272 are all 603e cores) */
> 0x7fff0000, 0x00820000, "827x & 828x",
> CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB,
> COMMON_PPC,
> 256, 256,
> __setup_cpu_603
> },
>
> Regards
> Dennis
>
>
> ----- Original Message -----
> From: "Kumar Gala" <kumar.gala@freescale.com>
> To: "Nai-Hsien" <dennis@loop.com.tw>
> Cc: <linuxppc-embedded@ozlabs.org>; "Andrew Williams"
<awilliam@nortel.com>
> Sent: Wednesday, June 08, 2005 9:52 PM
> Subject: Re: MPC8272 runs application with segmentation fault
>
>
> > A few questions, where did you get the kernel for the 8272 you are
> > using? Can you report back what libc version you are running with.
> > Also, can see what entry in arch/ppc/kernel/cputable.c has a pvr_value
> > of 0x00820000 and report that back as well.
> >
> > - kumar
> >
> > On Jun 8, 2005, at 8:39 AM, Nai-Hsien wrote:
> >
> > > Andrew,
> > > I believe I already modify my u-boot to detect the processor.
> > >
> > > If I statically link my program, I find that the program can run
> > > on my MPC8272 platform properly, so I think maybe the problem
> > > is caused by shared library. However, the same file system (of course,
> > > same shared library) can run on my MPC8245 platform.
> > >
> > > With the observation, I think my kernel is not handling shared library
> > > properly. Is there any part of the kernel I should check?
> > >
> > > I added some code in do_page_fault() to dump some information, shown
> > > as below, when my program get problem.
> > >
> > > PID=34(console): Trap=300, NIP=0x0ffc6d90, LR=0x0ffc6d20, VM:
> > > (start=0x30000000,
> > > end=0x30017000, flags=0x00000875), addr=0x2e313056
> > > Segmentation fault
> > >
> > > Thank you
> > > Dennis
> > >
> > >
> > > ----- Original Message -----
> > > From: Andrew <mailto:awilliam@nortel.com> Williams
> > > To: Nai-Hsien <mailto:dennis@loop.com.tw> ;
> > > linuxppc-embedded@ozlabs.org
> > > Sent: Tuesday, June 07, 2005 10:17 PM
> > > Subject: RE: MPC8272 runs application with segmentation fault
> > >
> > > Take a alook at the checkcpu() routine in /cpu/mpc8260/cpu.c .
> > > Validate that your CPU is correctly being identified, and thus
> > > initialized.
> > > We had identical symptoms with the 8270.
> > >
> > > We added the following after the case for the PVR_8260_HIP7:
> > >
> > > case PVR_8280a_HIP7:
> > > case PVR_8280_HIP7:
> > > k = 7;
> > > printf (CPU_ID_STR " (HiP%d Rev %02x, Mask ", k, rev);
> > > break;
> > >
> > > include/asm-ppc/processor.h
> > >
> > > #define PVR_8280_HIP7 0x80822013
> > > #define PVR_8280a_HIP7 0x80822014
> > >
> > > A.
> > >
> > > -----Original Message-----
> > > From: linuxppc-embedded-bounces@ozlabs.org
> > > [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Nai-Hsien
> > > Sent: June 7, 2005 9:11 AM
> > > To: linuxppc-embedded@ozlabs.org
> > > Subject: MPC8272 runs application with segmentation fault
> > >
> > >
> > > Dear experts,
> > >
> > > I have two hardware boards, one uses MPC8245 and the other one uses
> > > MPC8272.
> > > Initially, I use the MPC8245 board to port Linux 2.4.20 and write some
> > > applications.
> > > I already do a lot of test on the MPC8245 board and all my application
> > > programs work
> > > fine.
> > >
> > > After this, I use the same kernel configuration and same file system
> > > that are being used
> > > by the MPC8245 board to port the whole system to my MPC8272.
> > > Now, I can boot the kernel and run busybox well. However, when
> > > I run my application programs, I always get segmentation fault.
> > > Following is a strace
> > > dump. Could anybody give me some idea?
> > >
> > > Thank you
> > > Dennis
> > >
> > > ====================================================
> > > execve("sbin/console", ["sbin/console"], [/* 6 vars */]) = 0
> > > uname({sys="Linux", node="6200_linux", ...}) = 0
> > > brk(0) = 0x10059134
> > > open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
> > > directory)
> > > open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or
> > > directory)
> > > open("/lib/libncurses.so.5", O_RDONLY) = 3
> > > read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\001"...,
> > > 1024) = 1024
> > > fstat64(0x3, 0x7ffff098) = 0
> > > mmap(0xff97000, 362628, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> > > 0xff97000
> > > mprotect(0xffd4000, 112772, PROT_NONE) = 0
> > > mmap(0xffd7000, 86016, PROT_READ|PROT_WRITE|PROT_EXEC,
> > > MAP_PRIVATE|MAP_FIXED, 3, 0x30000) = 0xffd7000
> > > mmap(0xffec000, 14468, PROT_READ|PROT_WRITE|PROT_EXEC,
> > > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffec000
> > > close(3) = 0
> > > open("/lib/libdl.so.2", O_RDONLY) = 3
> > > read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\34"...,
> > > 1024) = 1024
> > > fstat64(0x3, 0x7ffff078) = 0
> > > mmap(0xff74000, 74812, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> > > 0xff74000
> > > mprotect(0xff77000, 62524, PROT_NONE) = 0
> > > mmap(0xff84000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC,
> > > MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xff84000
> > > close(3) = 0
> > > open("/lib/libnsl.so.1", O_RDONLY) = 3
> > > read(3,
> > > "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0A\274"..., 1024)
> > > = 1024
> > > fstat64(0x3, 0x7ffff058) = 0
> > > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> > > 0) = 0x30017000
> > > mmap(0xff3e000, 152068, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> > > 0xff3e000
> > > mprotect(0xff51000, 74244, PROT_NONE) = 0
> > > mmap(0xff5e000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC,
> > > MAP_PRIVATE|MAP_FIXED, 3, 0x10000) = 0xff5e000
> > > mmap(0xff61000, 8708, PROT_READ|PROT_WRITE|PROT_EXEC,
> > > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xff61000
> > > close(3) = 0
> > > open("/lib/libc.so.6", O_RDONLY) = 3
> > > read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\322"...,
> > > 1024) = 1024
> > > fstat64(0x3, 0x7ffff038) = 0
> > > mmap(0xfddd000, 1379388, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> > > 0xfddd000
> > > mprotect(0xff16000, 97340, PROT_NONE) = 0
> > > mmap(0xff1d000, 61440, PROT_READ|PROT_WRITE|PROT_EXEC,
> > > MAP_PRIVATE|MAP_FIXED, 3, 0x130000) = 0xff1d000
> > > mmap(0xff2c000, 7228, PROT_READ|PROT_WRITE|PROT_EXEC,
> > > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xff2c000
> > > close(3) = 0
> > > brk(0) = 0x10059134
> > > brk(0x1005a134) = 0x1005a134
> > > brk(0x1005b000) = 0x1005b000
> > > write(2, "before init_ncurses()\n", 22) = 22
> > > write(2, "before initscr()\n", 17) = 17
> > > access("/usr/share/terminfo/v/vt100", R_OK) = 0
> > > open("/usr/share/terminfo/v/vt100", O_RDONLY) = 3
> > > read(3, "\32\1,\0\25\0\7\0\16\1\3\2", 12) = 12
> > > read(3, "vt100|vt100-am|dec vt100 (w/adva"..., 44) = 44
> > > read(3, "\0\1\0\0\1\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\1", 21) = 21
> > > read(3, "\0", 1) = 1
> > > read(3, "P\0\10\0\30\0\377\377\377\377\377\377\3\0", 14) = 14
> > > read(3, "\377\377\0\0\2\0\4\0\25\0\32\0&\0.\0\377\377\377\3777\0"...,
> > > 540) = 540
> > > read(3, "\7\0\r\0\33[%i%p1%d;%p2%dr\0\33[3g\0\33[H\33[J"..., 515) =
515
> > > read(3, "", 1) = 0
> > > read(3, "", 10) = 0
> > > close(3) = 0
> > > -- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > > +++ killed by SIGSEGV +++
> > > Segmentation fault
> > >
> > >
> > >
> > > <ATT169162.txt>
> >
> >
>
^ permalink raw reply
* Re: PPC arch and spinlocks
From: Jeff Angielski @ 2005-06-08 15:26 UTC (permalink / raw)
To: Garcia Jérémie; +Cc: linuxppc-dev
In-Reply-To: <D4FDDD1349B5AC46B68FC26AD8AF42D6226B31@exnet.3il.fr>
On Wed, 2005-06-08 at 16:29 +0200, Garcia Jérémie wrote:
> Hi everybody, I need your help one more time.
> I'm new to kernel device driver (linux newbie) and I'd like to control concurrent access
> to our hardware resources. (I'm working on a ppc405EP platform uniprocessor)
You might find this guide useful:
http://www.kernelnewbies.org/documents/kdoc/kernel-locking/lklockingguide.html
Jeff Angielski
The PTR Group
^ permalink raw reply
* Re: [PATCH][4/5] RapidIO support: ppc32
From: Kumar Gala @ 2005-06-08 15:34 UTC (permalink / raw)
To: Matt Porter; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <20050607225210.A28898@cox.net>
On Jun 8, 2005, at 12:52 AM, Matt Porter wrote:
> On Tue, Jun 07, 2005 at 11:43:26PM -0500, Kumar Gala wrote:
>> Two questions:
>> 1. how well does will all of this handle > 32-bit phys addr?
>
> It does and it doesn't handle > 32-bit phys addr. It depends on which
> configuration you are talking about. If you are talking about I/O
>> 32-bit, it's no problem. If you are talking about handling DMA
>> 32-bit,
> then we need to handle a 64-bit DMA addr in the ppc32 implementations
> and
> also extend the arch messaging interface to let callers know when an
> implementation can handle high DMA (system memory >4GB). This is all
> pretty easy to handle once we need to support such a processor. So
> far, nothing is available publicly. :)
Well 8548 is semi-public :)
> For RIO MMIO purposes (which is functionality I'm working on now),
> it has the similar issues that PCI memory space has on processors with
> I/O above 4GB. However, on RIO our resources hold a bus address since
> a physical address doesn't make sense since address spaces our
> per-device.
> If we ever support a 66-bit address space device on 32-bit processor,
> we
> might need a u64 resource.
I assume you mean 36-bit, what would one do with 66-bit addresses :)
>> 2. can we make any of this a platform driver?
>
> Hrm, so you would rather see RIO host bridges look like a driver
> on another "bus"? I have seen them as a component just like PCI
> host bridges. That is, they are instantiated by arch-code and
> then initialized by a subsys initcall. This does mean that we
> will be enumerating much later (during driver initcalls), but
> it might be a better model if we ever see a rumored PCIE->RIO
> bridge. Supporting that as a RIO master port would require driver
> time init of the RIO fabric. There's some ordering issues that we'd
> have to see about working out. None of this is needed right now,
> though.
>
>> I would prefer if we could have the memory offsets and irq's not be
>> straight from the #define's
>
> I think this and #2 are separate issues. We can pass the mpc85xx
> rio init code some parameters to abstract things to different
> parts. This is similar to how we init different SoC's PCI host
> bridges with some common code on PPC32 (marvell, 85xx, etc).
>
> I was just looking at doing this to support RIO on the 8548. At
> the time I wrote this 85xx support there wasn't any info on the
> 8548 available, but it's an easy thing to extend.
Agreed, they are separate issues, I'm cool on waiting to see what
happens with RIO <-> PCIE bridges in the future. For now if you can
look at abstracting the offset, irq info that would be good (especially
since 8548 does msg'g a bit differently).
- kumar
^ permalink raw reply
* RE: root fs mount issue: Xilinx System ACE on PCI bus
From: Sanjay Bajaj @ 2005-06-08 15:36 UTC (permalink / raw)
To: Mark Chambers, Peter Ryser; +Cc: linuxppc-embedded
Thanks Mark and Peter for your responses.
I was not using devfs filesystem earlier. I included that in the kernel =
build and set the "root=3D" in the bootargs to "/dev/xsysace/disc0/part2 =
rw". A similar string I found in Xilinx ML300 documentation. It worked !
Thanks Again.
Sanjay
-----Original Message-----
From: Mark Chambers [mailto:markc@mail.com]
Sent: Tuesday, June 07, 2005 8:48 PM
To: Sanjay Bajaj
Subject: Re: root fs mount issue: Xilinx System ACE on PCI bus
Arggh, sorry, I told you wrong. It's "rootfstype=3D". Also, I see that =
the
command list I use (which came from u-boot) also has "noinitrd" in it. =
The
whole line is (just for a reference):
root=3D/dev/mtdblock0 rw noinitrd rootfstype=3Djffs2
ip=3D192.168.1.4:192.168.1.6:192.168.1.1:255.255.255.0:iView:eth0:off =
panic=3D1
I'm using devfs - are you?
----- Original Message -----=20
From: "Sanjay Bajaj" <sbajaj@tsi-telsys.com>
To: "Mark Chambers" <markc@mail.com>
Cc: <linuxppc-embedded@ozlabs.org>
Sent: Tuesday, June 07, 2005 1:02 PM
Subject: RE: root fs mount issue: Xilinx System ACE on PCI bus
Hi! Mark,
I did put in "rootfs=3Dext3", but, the result is still the same.
Sanjay
-----Original Message-----
From: Mark Chambers [mailto:markc@mail.com]
Sent: Tuesday, June 07, 2005 11:51 AM
To: Sanjay Bajaj
Subject: Re: root fs mount issue: Xilinx System ACE on PCI bus
Well, I'm no guru, but you could try adding a 'rootfs=3D" option to your
kernel command line (rootfs=3Djffs2, for instance, or ext2). Perhaps =
the
kernel is not able to automatically determine the filesystem. When you
'mount' you explicitly tell the kernel what kind of file system is on =
the
device.
Mark Chambers
----- Original Message -----=20
From: "Sanjay Bajaj" <sbajaj@tsi-telsys.com>
To: <linuxppc-embedded@ozlabs.org>
Sent: Tuesday, June 07, 2005 11:05 AM
Subject: root fs mount issue: Xilinx System ACE on PCI bus
Hi! Gurus,
Need some help in understanding root fs mounting. The setup we have here =
is
our hardware has Xilinx Virtex II pro chip that has System ACE hardware
connected to a compact flash. The Virtex II Pro is connected to Local =
PCI
bus which is run by PPC 440GX processor. I have ported the driver for
xsysace from ml300 config to our hardware (From OPB to PCI). When I boot
over nfs, I can easily mount the partictions on the compact flash. The =
nodes
in /dev directory are:
brw-r--r-- 1 root root 254, 0 Jun 3 13:04 xsysacea
brw-r--r-- 1 root root 254, 1 Jun 3 13:04 xsysacea1
brw-r--r-- 1 root root 254, 2 Jun 3 13:04 xsysacea2
When I try to boot from the commpact flash, the kernel panics. The =
edited
boot listing is as follows:
=3D> bootm
...
...
Kernel command line: root=3D/dev/xsysacea2 rw console=3DttyS0,9600 =
mem=3D128M
...
...
Partition check:
xsysacea: xsysacea1 xsysacea2
System ACE at 0xFFFC1000 mapped to 0xD2070000, irq=3D26, 500472KB
...
...
VFS: Cannot open root device "xsysacea2" or 00:00
Please append a correct "root=3D" boot option
Kernel panic: VFS: Unable to mount root fs on 00:00
<0>Rebooting in 180 seconds..
-------
What am I missing here? Any help is appreciated.
Thanks,
Sanjay
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [RFC] handle access to non-present IO ports on 8xx
From: Marcelo Tosatti @ 2005-06-08 9:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, linux-ppc-embedded
In-Reply-To: <1117750262.31082.73.camel@gaston>
On Fri, Jun 03, 2005 at 08:11:01AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2005-06-02 at 14:02 -0300, Marcelo Tosatti wrote:
> > Hi Ben,
> >
> > On Thu, Jun 02, 2005 at 12:46:32PM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2005-06-01 at 13:50 -0300, Marcelo Tosatti wrote:
> > >
> > > Hrm... removing a PCMCIA card triggers mchecks ? that is bad... With
> > > "proper" PCMCIA controllers, those are swallowed properly when the card
> > > is removed. The eating of the machine check is a bit too hackish to my
> > > taste... Better is to "not do that" by making sure the legacy crap isn't
> > > trying to tap unexisting ports, but then, if PCMCIA is also a
> > > problem...
> >
> > Well, cardmgr calls the driver's shutdown/close routine as soon as
> > the card is removed. Some of those methods write to IO registers in
> > the process (eg net/pcmcia/pcnet_cs.c).
> >
> > I dont see any elegant change that could be done in PCMCIA.
>
> I know, the thing is, on platforms with a "classical" PCI<->PCMCIA
> bridge, the bridge will not issue machine checks when the card is
> removed. I don't know if that is possible with your HW setup, I suppose
> you are hooking PCMCIA directly to the CPU IO bus ...
I think the PCMCIA bus is hooked directly to the CPU, yes.
> > One possibility that comes to mind would be to enforce the rule
> > that drivers should not writeout in case of a removal event,
>
> They can't know, they get the removal even too late. The driver may be
> in the middle of writing when you remove the card. If there is no HW way
> to prevent the machine check, then you'll need software recovery.
>
> > but that does not sound feasible to me: It just looks too messy,
> > however I have no good argument against it.
> >
> > Well, its restricted to 8xx (maybe 32-bit PPC) with PCMCIA, so its
> > just not worth the trouble?
>
> Hehe... dunno.
>
> > Hmmm... I'll look that up. My limited testing on HW in question does not
> > exhibit longer MCE delays than "twi/isync/nop" sequence - actually, it is
> > always triggered during the IO access instruction itself.
>
> I suppose the 8xx may actually be quite synchronous on IOs then...
>
> > Where can I find information about write posting on 8xx? Is there a
> > term for it used in PPC documentation? I can't find anything...
>
> Well, do you have a store queue ? What does the 8xx manual says about
> ordering & queueing of non cacheable loads & stores ? Maybe the chip is
> fully synchronous on IOs ?
It seems so, yes.
Section 6.1 of MPC860UM.pdf:
"All exceptions associated with memory are implemented as precise, which
means that a load/store instruction is not complete until all possible
error indications are sampled from the load/store bus.
This also imples that a store or nonspeculative load instruction is
not issued to the load/store bus until all previous instructions have
completed."
I'll prepare a new patch reflecting this information, thanks again
Ben.
^ permalink raw reply
* Re: [PATCH][4/5] RapidIO support: ppc32
From: Matt Porter @ 2005-06-08 16:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <609b05dd2d9806d7d1cd68696b1f49e2@freescale.com>
On Wed, Jun 08, 2005 at 10:34:03AM -0500, Kumar Gala wrote:
>
> On Jun 8, 2005, at 12:52 AM, Matt Porter wrote:
>
> > On Tue, Jun 07, 2005 at 11:43:26PM -0500, Kumar Gala wrote:
> >> Two questions:
> >> 1. how well does will all of this handle > 32-bit phys addr?
> >
> > It does and it doesn't handle > 32-bit phys addr. It depends on which
> > configuration you are talking about. If you are talking about I/O
> >> 32-bit, it's no problem. If you are talking about handling DMA
> >> 32-bit,
> > then we need to handle a 64-bit DMA addr in the ppc32 implementations
> > and
> > also extend the arch messaging interface to let callers know when an
> > implementation can handle high DMA (system memory >4GB). This is all
> > pretty easy to handle once we need to support such a processor. So
> > far, nothing is available publicly. :)
>
> Well 8548 is semi-public :)
Heh, well my definition is when Fscale has the reference manual
downloadable from the main website...as of last night that wasn't
the case for 8548. :)
<snip>
> >> I would prefer if we could have the memory offsets and irq's not be
> >> straight from the #define's
> >
> > I think this and #2 are separate issues. We can pass the mpc85xx
> > rio init code some parameters to abstract things to different
> > parts. This is similar to how we init different SoC's PCI host
> > bridges with some common code on PPC32 (marvell, 85xx, etc).
> >
> > I was just looking at doing this to support RIO on the 8548. At
> > the time I wrote this 85xx support there wasn't any info on the
> > 8548 available, but it's an easy thing to extend.
>
> Agreed, they are separate issues, I'm cool on waiting to see what
> happens with RIO <-> PCIE bridges in the future. For now if you can
> look at abstracting the offset, irq info that would be good (especially
> since 8548 does msg'g a bit differently).
No problem. The first "ppc85xx_rio.c" was only intended to work on
the 8540/8560 stuff where I had hardware. From my look at 8548, it
shouldn't take much work.
-Matt
^ permalink raw reply
* Re: consistent_alloc() on 82xx
From: Dan Malek @ 2005-06-08 16:12 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20050608102938.023f271f.ajz@cambridgebroadband.com>
On Jun 8, 2005, at 5:29 AM, Alex Zeffertt wrote:
> Does anybody know why it isn't built for 6xx cores?
Because 6xx cores are cache coherent and there shouldn't
be any need for "uncached" memory regions.
> I'm working on the ATM driver and it seems that certain external memory
> areas accessed by the PQII CPM by-pass the cache.
That's news to me, and I've written lots of CPM drivers, including ATM.
Do you have a specific example?
Thanks.
-- Dan
^ permalink raw reply
* Re: syntax for clobber list with inline assembly
From: Chris Friesen @ 2005-06-08 21:39 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Linux PPC Dev
In-Reply-To: <455acab93dd9ab20cbbc1cff400f84e3@penguinppc.org>
Hollis Blanchard wrote:
> But it should be said that much better style is to let the compiler
> choose registers for you, i.e. don't hardcode register numbers at all.
> For example (well, it's contrived, but I hope you get the idea):
Certainly that would be the normal case.
In this particular case I'm writing some code to test whether my
function to flush/clear the entire cache is properly working.
It uses self-modifying code, and I've got some instructions using r3
hardcoded as hex. Thus the specific use of r3.
Chris
^ permalink raw reply
* Slim open firmware implementation
From: Benjamin Herrenschmidt @ 2005-06-08 23:04 UTC (permalink / raw)
To: linuxppc-embedded
IBM just released:
http://www-128.ibm.com/developerworks/power/library/pa-dw-slof.html?S_TACT=105AGX16&S_CMP=HP
Ben.
^ permalink raw reply
* MPC52xx: sysfs failure on adding new device driver
From: Grant Likely @ 2005-06-08 23:51 UTC (permalink / raw)
To: linuxppc-embedded
I'm working on an MPC52xx SPI device driver using one of the PSC.=20
However, when I call driver_register() I get a failure (-17, EEXISTS)
with a traceback (posted below).
I've tracked it down to failing when trying to create a sysfs entry
for the driver. It fails because sysfs tries to create a directory
that already exists (mpc52xx_psc). The directory was already created
when the psc serial port device driver was registered.
>From what I can tell, I should be able to register more than one
driver for a particular device name (mpc52xx_psc). Otherwise I would
need to change arch/ppc/syslib/mpc52xx_devices.c to have a different
name for each psc. If I change the sysfs code to ignore the failure
to create a directory then the driver seems to register fine.
I've attached a simple patch that reproduces the problem with stock
linux-2.6.12-rc6. Am I doing something wrong here or is this a bug in
the sysfs code for the platform bus?
Thanks in advance,
g.
----------------------------------------------------------
Patch follows:
----------------------------------------------------------
diff -ruN linux-2.6.11.orig/.config linux-2.6.11/.config
--- linux-2.6.11.orig/.config 2005-06-08 17:22:48.000000000 -0600
+++ linux-2.6.11/.config 2005-06-08 17:29:56.000000000 -0600
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc6
-# Wed Jun 8 17:22:48 2005
+# Wed Jun 8 17:29:56 2005
#
CONFIG_MMU=3Dy
CONFIG_GENERIC_HARDIRQS=3Dy
@@ -460,6 +460,12 @@
# CONFIG_INFINIBAND is not set
#
+# SPI support
+#
+CONFIG_SPI=3Dy
+CONFIG_SPI_MPC52XX_PSC=3Dy
+
+#
# File systems
#
# CONFIG_EXT2_FS is not set
diff -ruN linux-2.6.11.orig/.config.old linux-2.6.11/.config.old
--- linux-2.6.11.orig/.config.old 2005-06-08 17:22:31.000000000 -0600
+++ linux-2.6.11/.config.old 2005-06-08 17:22:48.000000000 -0600
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.12-rc2
-# Thu May 19 12:30:43 2005
+# Linux kernel version: 2.6.12-rc6
+# Wed Jun 8 17:22:48 2005
#
CONFIG_MMU=3Dy
CONFIG_GENERIC_HARDIRQS=3Dy
@@ -11,6 +11,7 @@
CONFIG_PPC=3Dy
CONFIG_PPC32=3Dy
CONFIG_GENERIC_NVRAM=3Dy
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=3Dy
#
# Code maturity level options
@@ -35,6 +36,8 @@
CONFIG_KALLSYMS=3Dy
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_PRINTK=3Dy
+CONFIG_BUG=3Dy
CONFIG_BASE_FULL=3Dy
CONFIG_FUTEX=3Dy
CONFIG_EPOLL=3Dy
@@ -62,6 +65,7 @@
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_E500 is not set
+CONFIG_PPC_FPU=3Dy
# CONFIG_ALTIVEC is not set
# CONFIG_TAU is not set
# CONFIG_CPU_FREQ is not set
@@ -110,6 +114,7 @@
CONFIG_BINFMT_ELF=3Dy
# CONFIG_BINFMT_MISC is not set
# CONFIG_CMDLINE_BOOL is not set
+CONFIG_ISA_DMA_API=3Dy
#
# Bus options
@@ -347,7 +352,6 @@
# CONFIG_SERIO_LIBPS2 is not set
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
-CONFIG_SOUND_GAMEPORT=3Dy
#
# Character devices
diff -ruN linux-2.6.11.orig/.version linux-2.6.11/.version
--- linux-2.6.11.orig/.version 2005-06-08 17:24:33.000000000 -0600
+++ linux-2.6.11/.version 2005-06-08 17:30:04.000000000 -0600
@@ -1 +1 @@
-1
+2
Files linux-2.6.11.orig/arch/ppc/boot/images/uImage and
linux-2.6.11/arch/ppc/boot/images/uImage differ
Files linux-2.6.11.orig/arch/ppc/boot/images/vmlinux.bin and
linux-2.6.11/arch/ppc/boot/images/vmlinux.bin differ
Files linux-2.6.11.orig/arch/ppc/boot/images/vmlinux.gz and
linux-2.6.11/arch/ppc/boot/images/vmlinux.gz differ
diff -ruN linux-2.6.11.orig/drivers/Kconfig linux-2.6.11/drivers/Kconfig
--- linux-2.6.11.orig/drivers/Kconfig 2005-03-02 00:38:26.000000000 -0700
+++ linux-2.6.11/drivers/Kconfig 2005-06-08 17:27:23.000000000 -0600
@@ -58,4 +58,6 @@
source "drivers/infiniband/Kconfig"
+source "drivers/spi/Kconfig"
+
endmenu
diff -ruN linux-2.6.11.orig/drivers/Makefile linux-2.6.11/drivers/Makefile
--- linux-2.6.11.orig/drivers/Makefile 2005-06-08 17:22:08.000000000 -0600
+++ linux-2.6.11/drivers/Makefile 2005-06-08 17:27:13.000000000 -0600
@@ -64,3 +64,4 @@
obj-$(CONFIG_BLK_DEV_SGIIOC4) +=3D sn/
obj-y +=3D firmware/
obj-$(CONFIG_CRYPTO) +=3D crypto/
+obj-$(CONFIG_SPI) +=3D spi/
diff -ruN linux-2.6.11.orig/drivers/spi/Kconfig
linux-2.6.11/drivers/spi/Kconfig---
linux-2.6.11.orig/drivers/spi/Kconfig 1969-12-31
17:00:00.000000000 -0700
+++ linux-2.6.11/drivers/spi/Kconfig 2005-06-08 17:29:37.000000000 -0600
@@ -0,0 +1,19 @@
+#
+# Character device configuration
+#
+
+menu "SPI support"
+
+config SPI
+ tristate "SPI support"
+ ---help---
+ SPI is a serial bus protocol for connecting between ICs
+
+config SPI_MPC52XX_PSC
+ tristate "SPI bus via MPC5xxx PSC port"
+ depends on SPI
+ help
+ Say Y here if you want SPI via an MPC5xxx PSC port.
+
+endmenu
+
diff -ruN linux-2.6.11.orig/drivers/spi/Makefile
linux-2.6.11/drivers/spi/Makefile
--- linux-2.6.11.orig/drivers/spi/Makefile 1969-12-31
17:00:00.000000000 -0700
+++ linux-2.6.11/drivers/spi/Makefile 2005-06-08 17:29:17.000000000 -0600
@@ -0,0 +1,6 @@
+#
+# Makefile for the spi core.
+#
+
+obj-$(CONFIG_SPI_MPC52XX_PSC) +=3D spi-mpc5xxx-psc.o
+
diff -ruN linux-2.6.11.orig/drivers/spi/spi-mpc5xxx-psc.c
linux-2.6.11/drivers/spi/spi-mpc5xxx-psc.c
--- linux-2.6.11.orig/drivers/spi/spi-mpc5xxx-psc.c 1969-12-31
17:00:00.000000000 -0700
+++ linux-2.6.11/drivers/spi/spi-mpc5xxx-psc.c 2005-06-08
17:29:07.000000000 -0600
@@ -0,0 +1,60 @@
+
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/cdev.h>
+
+#include <asm/mpc52xx.h>
+#include <asm/mpc52xx_psc.h>
+
+MODULE_LICENSE("Dual BSD/GPL");
+
+static int __devinit
+spi_mpc52xx_psc_probe(struct device *dev)
+{
+ struct platform_device *pdev =3D to_platform_device(dev);
+ /*struct resource *res =3D pdev->resource;*/
+ int idx =3D pdev->id;
+
+ printk(KERN_ALERT "spi-mpc52xx-psc: probing idx=3D%i\n", idx);
+
+ if (!mpc52xx_match_psc_function(idx, "spi"))
+ {
+ printk(KERN_ALERT "function not matched!\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int
+spi_mpc52xx_psc_remove(struct device *dev)
+{
+ return 0;
+}
+
+static struct device_driver spi_mpc52xx_psc_platform_driver =3D {
+ .name =3D "mpc52xx-psc",
+ .bus =3D &platform_bus_type,
+ .probe =3D spi_mpc52xx_psc_probe,
+ .remove =3D spi_mpc52xx_psc_remove,
+};
+
+static int __init spi_mpc52xx_psc_init(void)
+{
+ int ret;
+
+ printk(KERN_ALERT "spi_mpc52xx_psc: initializing\n");
+
+ ret =3D driver_register(&spi_mpc52xx_psc_platform_driver);
+ return ret;
+}
+
+static void __exit spi_mpc52xx_psc_exit(void)
+{
+ driver_unregister(&spi_mpc52xx_psc_platform_driver);
+ printk(KERN_ALERT "spi_mpc52xx_psc: exiting\n");
+}
+
+module_init(spi_mpc52xx_psc_init);
+module_exit(spi_mpc52xx_psc_exit);
diff -ruN linux-2.6.11.orig/include/config/spi/mpc52xx/psc.h
linux-2.6.11/include/config/spi/mpc52xx/psc.h
--- linux-2.6.11.orig/include/config/spi/mpc52xx/psc.h 1969-12-31
17:00:00.000000000 -0700
+++ linux-2.6.11/include/config/spi/mpc52xx/psc.h 2005-06-08
17:29:56.000000000 -0600
@@ -0,0 +1 @@
+#define CONFIG_SPI_MPC52XX_PSC 1
diff -ruN linux-2.6.11.orig/include/config/spi.h
linux-2.6.11/include/config/spi.h
--- linux-2.6.11.orig/include/config/spi.h 1969-12-31
17:00:00.000000000 -0700
+++ linux-2.6.11/include/config/spi.h 2005-06-08 17:29:56.000000000 -0600
@@ -0,0 +1 @@
+#define CONFIG_SPI 1
diff -ruN linux-2.6.11.orig/include/linux/autoconf.h
linux-2.6.11/include/linux/autoconf.h
--- linux-2.6.11.orig/include/linux/autoconf.h 2005-06-08
17:22:48.000000000 -0600
+++ linux-2.6.11/include/linux/autoconf.h 2005-06-08
17:29:56.000000000 -0600
@@ -1,7 +1,7 @@
/*
* Automatically generated C config: don't edit
* Linux kernel version: 2.6.12-rc6
- * Wed Jun 8 17:22:48 2005
+ * Wed Jun 8 17:29:56 2005
*/
#define AUTOCONF_INCLUDED
#define CONFIG_MMU 1
@@ -461,6 +461,12 @@
#undef CONFIG_INFINIBAND
/*
+ * SPI support
+ */
+#define CONFIG_SPI 1
+#define CONFIG_SPI_MPC52XX_PSC 1
+
+/*
* File systems
*/
#undef CONFIG_EXT2_FS
----------------------------------------------------------
Boot log follows:
----------------------------------------------------------
## Booting image at 00100000 ...
Image Name: Linux-2.6.12-rc6-lite5200
Created: 2005-06-08 23:30:09 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 571225 Bytes =3D 557.8 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
arch: exit
Linux version 2.6.12-rc6-lite5200 (glikely@trillian) (gcc version 3.4.3) #2=
Wed
Jun 8 17:30:04 MDT 2005
Built 1 zonelists
Kernel command line: console=3DttyS0,115200
mtdparts=3Dphys_mapped_flash:14M(jffs2),1M(kernel),1M(boot)
root=3D/dev/mtdblock0 rootfstype=3Djffs2 rw
PID hash table entries: 512 (order: 9, 8192 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 63616k available (908k kernel code, 256k data, 72k init, 0k highmem=
)
Mount-cache hash table entries: 512
Linux NoNET1.0 for Linux 2.6
PCI: Probing PCI hardware
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
Serial: MPC52xx PSC driver
ttyS0 at MMIO 0xf0002000 (irq =3D 39) is a MPC52xx PSC
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
physmap flash device: 1000000 at ff000000
phys_mapped_flash: Found 1 x8 devices at 0x0 in 8-bit bank
phys_mapped_flash: Found 1 x8 devices at 0x800000 in 8-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
phys_mapped_flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
3 cmdlinepart partitions found on MTD device phys_mapped_flash
Creating 3 MTD partitions on "phys_mapped_flash":
0x00000000-0x00e00000 : "jffs2"
0x00e00000-0x00f00000 : "kernel"
0x00f00000-0x01000000 : "boot"
mice: PS/2 mouse device common for all mice
spi_mpc52xx_psc: initializing
kobject_register failed for mpc52xx-psc (-17)
Call trace:
[c0099128] kobject_register+0x60/0x78
[c00bc5ac] bus_add_driver+0x78/0x178
[c00bccc8] driver_register+0x30/0x40
[c0125b90] spi_mpc52xx_psc_init+0x24/0x34
[c0003944] init+0x7c/0x22c
[c0006a04] kernel_thread+0x44/0x60
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 72k init
ifconfig: socket: Function not implemented
route: socket: Function not implemented
/etc/rcS: 7: /usr/sbin/telnetd: not f\uffff
BusyBox v1.00 (2005.05.19-06:22+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
/ #
^ permalink raw reply
* [PATCH] ppc32: remove orphaned ppc4xx_kgdb.c
From: Matt Porter @ 2005-06-09 4:09 UTC (permalink / raw)
To: akpm; +Cc: akonovalov, linuxppc-embedded
Removes ppc4xx_kgdb.c which is no longer being used. Pointed
out by Andrei Konovalov.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
diff --git a/arch/ppc/syslib/ppc4xx_kgdb.c b/arch/ppc/syslib/ppc4xx_kgdb.c
deleted file mode 100644
--- a/arch/ppc/syslib/ppc4xx_kgdb.c
+++ /dev/null
@@ -1,124 +0,0 @@
-#include <linux/config.h>
-#include <linux/types.h>
-#include <asm/ibm4xx.h>
-#include <linux/kernel.h>
-
-
-
-#define LSR_DR 0x01 /* Data ready */
-#define LSR_OE 0x02 /* Overrun */
-#define LSR_PE 0x04 /* Parity error */
-#define LSR_FE 0x08 /* Framing error */
-#define LSR_BI 0x10 /* Break */
-#define LSR_THRE 0x20 /* Xmit holding register empty */
-#define LSR_TEMT 0x40 /* Xmitter empty */
-#define LSR_ERR 0x80 /* Error */
-
-#include <platforms/4xx/ibm_ocp.h>
-
-extern struct NS16550* COM_PORTS[];
-#ifndef NULL
-#define NULL 0x00
-#endif
-
-static volatile struct NS16550 *kgdb_debugport = NULL;
-
-volatile struct NS16550 *
-NS16550_init(int chan)
-{
- volatile struct NS16550 *com_port;
- int quot;
-#ifdef BASE_BAUD
- quot = BASE_BAUD / 9600;
-#else
- quot = 0x000c; /* 0xc = 9600 baud (on a pc) */
-#endif
-
- com_port = (struct NS16550 *) COM_PORTS[chan];
-
- com_port->lcr = 0x00;
- com_port->ier = 0xFF;
- com_port->ier = 0x00;
- com_port->lcr = com_port->lcr | 0x80; /* Access baud rate */
- com_port->dll = ( quot & 0x00ff ); /* 0xc = 9600 baud */
- com_port->dlm = ( quot & 0xff00 ) >> 8;
- com_port->lcr = 0x03; /* 8 data, 1 stop, no parity */
- com_port->mcr = 0x00; /* RTS/DTR */
- com_port->fcr = 0x07; /* Clear & enable FIFOs */
-
- return( com_port );
-}
-
-
-void
-NS16550_putc(volatile struct NS16550 *com_port, unsigned char c)
-{
- while ((com_port->lsr & LSR_THRE) == 0)
- ;
- com_port->thr = c;
- return;
-}
-
-unsigned char
-NS16550_getc(volatile struct NS16550 *com_port)
-{
- while ((com_port->lsr & LSR_DR) == 0)
- ;
- return (com_port->rbr);
-}
-
-unsigned char
-NS16550_tstc(volatile struct NS16550 *com_port)
-{
- return ((com_port->lsr & LSR_DR) != 0);
-}
-
-
-#if defined(CONFIG_KGDB_TTYS0)
-#define KGDB_PORT 0
-#elif defined(CONFIG_KGDB_TTYS1)
-#define KGDB_PORT 1
-#elif defined(CONFIG_KGDB_TTYS2)
-#define KGDB_PORT 2
-#elif defined(CONFIG_KGDB_TTYS3)
-#define KGDB_PORT 3
-#else
-#error "invalid kgdb_tty port"
-#endif
-
-void putDebugChar( unsigned char c )
-{
- if ( kgdb_debugport == NULL )
- kgdb_debugport = NS16550_init(KGDB_PORT);
- NS16550_putc( kgdb_debugport, c );
-}
-
-int getDebugChar( void )
-{
- if (kgdb_debugport == NULL)
- kgdb_debugport = NS16550_init(KGDB_PORT);
-
- return(NS16550_getc(kgdb_debugport));
-}
-
-void kgdb_interruptible(int enable)
-{
- return;
-}
-
-void putDebugString(char* str)
-{
- while (*str != '\0') {
- putDebugChar(*str);
- str++;
- }
- putDebugChar('\r');
- return;
-}
-
-void
-kgdb_map_scc(void)
-{
- printk("kgdb init \n");
- kgdb_debugport = NS16550_init(KGDB_PORT);
-}
^ permalink raw reply
* [PATCH] ppc32: Add support for MPC8245 8250 serial ports on Sandpoint
From: Kumar Gala @ 2005-06-09 5:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Added platform device initialization for the two 8250 style UARTs
that exist on the MPC8245. Additionally, updated the Sandpoint
code to enable one of these UARTs if an MPC8245 is connected to
it.
Signed-off-by: Matt McClintock <msm@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 55d8b4cb4e140c5070b49dbda9798ae41901f8f9
tree 5cd65f7fffed04ddca7788510b1d24ba0a5e5a70
parent a50a1bad037d7c6621ce360310ae810e7bc822c7
author Matt McClintock <msm@freescale.com> Thu, 09 Jun 2005 00:08:26 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 09 Jun 2005 00:08:26 -0500
arch/ppc/platforms/sandpoint.c | 20 ++++++++++++++++++++
arch/ppc/syslib/mpc10x_common.c | 20 ++++++++++++++++++++
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/platforms/sandpoint.c b/arch/ppc/platforms/sandpoint.c
--- a/arch/ppc/platforms/sandpoint.c
+++ b/arch/ppc/platforms/sandpoint.c
@@ -81,6 +81,7 @@
#include <linux/serial.h>
#include <linux/tty.h> /* for linux/serial_core.h */
#include <linux/serial_core.h>
+#include <linux/serial_8250.h>
#include <asm/system.h>
#include <asm/pgtable.h>
@@ -99,6 +100,7 @@
#include <asm/mpc10x.h>
#include <asm/pci-bridge.h>
#include <asm/kgdb.h>
+#include <asm/ppc_sys.h>
#include "sandpoint.h"
@@ -304,6 +306,24 @@ sandpoint_setup_arch(void)
/* Lookup PCI host bridges */
sandpoint_find_bridges();
+
+ if (strncmp (cur_ppc_sys_spec->ppc_sys_name, "8245", 4) == 0)
+ {
+ bd_t *bp = (bd_t *)__res;
+ struct plat_serial8250_port *pdata;
+ pdata = (struct plat_serial8250_port *) ppc_sys_get_pdata(MPC10X_DUART);
+
+ if (pdata)
+ {
+ pdata[0].uartclk = bp->bi_busfreq;
+ pdata[0].membase = ioremap(pdata[0].mapbase, 0x100);
+
+ /* this disables the 2nd serial port on the DUART
+ * since the sandpoint does not have it connected */
+ pdata[1].uartclk = 0;
+ pdata[1].irq = 0;
+ pdata[1].mapbase = 0;
+ }
printk(KERN_INFO "Motorola SPS Sandpoint Test Platform\n");
printk(KERN_INFO "Port by MontaVista Software, Inc. (source@mvista.com)\n");
diff --git a/arch/ppc/syslib/mpc10x_common.c b/arch/ppc/syslib/mpc10x_common.c
--- a/arch/ppc/syslib/mpc10x_common.c
+++ b/arch/ppc/syslib/mpc10x_common.c
@@ -44,10 +44,12 @@
#define MPC10X_I2C_IRQ (EPIC_IRQ_BASE + NUM_8259_INTERRUPTS)
#define MPC10X_DMA0_IRQ (EPIC_IRQ_BASE + 1 + NUM_8259_INTERRUPTS)
#define MPC10X_DMA1_IRQ (EPIC_IRQ_BASE + 2 + NUM_8259_INTERRUPTS)
+#define MPC10X_UART0_IRQ (EPIC_IRQ_BASE + 4 + NUM_8259_INTERRUPTS)
#else
#define MPC10X_I2C_IRQ -1
#define MPC10X_DMA0_IRQ -1
#define MPC10X_DMA1_IRQ -1
+#define MPC10X_UART0_IRQ -1
#endif
static struct fsl_i2c_platform_data mpc10x_i2c_pdata = {
@@ -55,6 +57,16 @@ static struct fsl_i2c_platform_data mpc1
};
static struct plat_serial8250_port serial_platform_data[] = {
+ [0] = {
+ .mapbase = 0x4500,
+ .iotype = UPIO_MEM,
+ .flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST,
+ },
+ [1] = {
+ .mapbase = 0x4600,
+ .iotype = UPIO_MEM,
+ .flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST,
+ },
{ },
};
@@ -399,6 +411,12 @@ mpc10x_bridge_init(struct pci_controller
ppc_sys_platform_devices[MPC10X_DMA1].resource[1].start = MPC10X_DMA1_IRQ;
ppc_sys_platform_devices[MPC10X_DMA1].resource[1].end = MPC10X_DMA1_IRQ;
+ serial_platform_data[0].mapbase += phys_eumb_base;
+ serial_platform_data[0].irq = MPC10X_UART0_IRQ;
+
+ serial_platform_data[1].mapbase += phys_eumb_base;
+ serial_platform_data[1].irq = MPC10X_UART0_IRQ + 1;
+
/*
* 8240 erratum 26, 8241/8245 erratum 29, 107 erratum 23: speculative
* PCI reads may return stale data so turn off.
@@ -597,6 +615,8 @@ void __init mpc10x_set_openpic(void)
openpic_set_sources(EPIC_IRQ_BASE, 3, OpenPIC_Addr + 0x11020);
/* Skip reserved space and map Message Unit Interrupt (I2O) */
openpic_set_sources(EPIC_IRQ_BASE + 3, 1, OpenPIC_Addr + 0x110C0);
+ /* Skip reserved space and map Serial Interupts */
+ openpic_set_sources(EPIC_IRQ_BASE + 4, 2, OpenPIC_Addr + 0x11120);
openpic_init(NUM_8259_INTERRUPTS);
}
^ permalink raw reply
* [PATCH] ppc32: Added support for all MPC8548 internal interrupts
From: Kumar Gala @ 2005-06-09 5:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
The MPC8548 has 48 internal interrupts and 12 external interrupts. The
previous generation PowerQUICC III devices only had 32 internal and 12
external interrupts on the primary interrupt controller.
Expanded the number of internal interrupts to 48 for all PowerQUICC III
processors and moved the interrupt numbers for the external after the 48
internal interrupt lines, rather than putting the 12 new internal
interrupts at the end and ifdef'ng the whole mess. As parted of this
created a macro which represents the internal interrupt senses since
they are the same on all PQ3 processors.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit d754db8e39a79ae9a159f747511889647e46748a
tree f7985574e2307406bdfea668a937f02effbc3e2d
parent 4c239e81dc954e513ea24fd20963122cebef2bd8
author Kumar K. Gala <kumar.gala@freescale.com> Thu, 09 Jun 2005 00:19:15 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 09 Jun 2005 00:19:15 -0500
arch/ppc/platforms/85xx/mpc85xx_ads_common.c | 36 +-----------------
arch/ppc/platforms/85xx/mpc85xx_cds_common.c | 41 +++------------------
arch/ppc/platforms/85xx/sbc85xx.c | 36 +-----------------
arch/ppc/platforms/85xx/stx_gp3.c | 36 +-----------------
include/asm-ppc/irq.h | 28 +++++++-------
include/asm-ppc/mpc85xx.h | 51 ++++++++++++++++++++++++++
6 files changed, 77 insertions(+), 151 deletions(-)
diff --git a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
+++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
@@ -59,40 +59,8 @@ extern unsigned long total_memory; /* in
unsigned char __res[sizeof (bd_t)];
/* Internal interrupts are all Level Sensitive, and Positive Polarity */
-
static u_char mpc85xx_ads_openpic_initsenses[] __initdata = {
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 0: L2 Cache */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 1: ECM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 2: DDR DRAM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 3: LBIU */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 4: DMA 0 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 5: DMA 1 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 6: DMA 2 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 7: DMA 3 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 8: PCI/PCI-X */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 9: RIO Inbound Port Write Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 10: RIO Doorbell Inbound */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 11: RIO Outbound Message */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 12: RIO Inbound Message */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 13: TSEC 0 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 14: TSEC 0 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 15: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 16: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 17: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 18: TSEC 0 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 19: TSEC 1 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 20: TSEC 1 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 21: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 22: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 23: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 24: TSEC 1 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 25: Fast Ethernet */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 26: DUART */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 27: I2C */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 28: Performance Monitor */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 29: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 30: CPM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 31: Unused */
+ MPC85XX_INTERNAL_IRQ_SENSES,
0x0, /* External 0: */
#if defined(CONFIG_PCI)
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 1: PCI slot 0 */
@@ -159,7 +127,7 @@ mpc85xx_ads_init_IRQ(void)
/* Skip reserved space and internal sources */
openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
/* Map PIC IRQs 0-11 */
- openpic_set_sources(32, 12, OpenPIC_Addr + 0x10000);
+ openpic_set_sources(48, 12, OpenPIC_Addr + 0x10000);
/* we let openpic interrupts starting from an offset, to
* leave space for cascading interrupts underneath.
diff --git a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
@@ -73,40 +73,8 @@ static int cds_pci_slot = 2;
static volatile u8 * cadmus;
/* Internal interrupts are all Level Sensitive, and Positive Polarity */
-
static u_char mpc85xx_cds_openpic_initsenses[] __initdata = {
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 0: L2 Cache */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 1: ECM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 2: DDR DRAM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 3: LBIU */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 4: DMA 0 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 5: DMA 1 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 6: DMA 2 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 7: DMA 3 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 8: PCI/PCI-X */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 9: RIO Inbound Port Write Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 10: RIO Doorbell Inbound */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 11: RIO Outbound Message */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 12: RIO Inbound Message */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 13: TSEC 0 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 14: TSEC 0 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 15: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 16: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 17: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 18: TSEC 0 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 19: TSEC 1 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 20: TSEC 1 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 21: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 22: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 23: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 24: TSEC 1 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 25: Fast Ethernet */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 26: DUART */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 27: I2C */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 28: Performance Monitor */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 29: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 30: CPM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 31: Unused */
+ MPC85XX_INTERNAL_IRQ_SENSES,
#if defined(CONFIG_PCI)
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 0: PCI1 slot */
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 1: PCI1 slot */
@@ -182,7 +150,6 @@ void __init
mpc85xx_cds_init_IRQ(void)
{
bd_t *binfo = (bd_t *) __res;
- int i;
/* Determine the Physical Address of the OpenPIC regs */
phys_addr_t OpenPIC_PAddr = binfo->bi_immr_base + MPC85xx_OPENPIC_OFFSET;
@@ -191,9 +158,13 @@ mpc85xx_cds_init_IRQ(void)
OpenPIC_NumInitSenses = sizeof (mpc85xx_cds_openpic_initsenses);
/* Skip reserved space and internal sources */
+#ifdef CONFIG_MPC8548
+ openpic_set_sources(0, 48, OpenPIC_Addr + 0x10200);
+#else
openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
+#endif
/* Map PIC IRQs 0-11 */
- openpic_set_sources(32, 12, OpenPIC_Addr + 0x10000);
+ openpic_set_sources(48, 12, OpenPIC_Addr + 0x10000);
/* we let openpic interrupts starting from an offset, to
* leave space for cascading interrupts underneath.
diff --git a/arch/ppc/platforms/85xx/sbc85xx.c b/arch/ppc/platforms/85xx/sbc85xx.c
--- a/arch/ppc/platforms/85xx/sbc85xx.c
+++ b/arch/ppc/platforms/85xx/sbc85xx.c
@@ -59,40 +59,8 @@ unsigned long pci_dram_offset = 0;
extern unsigned long total_memory; /* in mm/init */
/* Internal interrupts are all Level Sensitive, and Positive Polarity */
-
static u_char sbc8560_openpic_initsenses[] __initdata = {
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 0: L2 Cache */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 1: ECM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 2: DDR DRAM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 3: LBIU */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 4: DMA 0 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 5: DMA 1 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 6: DMA 2 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 7: DMA 3 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 8: PCI/PCI-X */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 9: RIO Inbound Port Write Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 10: RIO Doorbell Inbound */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 11: RIO Outbound Message */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 12: RIO Inbound Message */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 13: TSEC 0 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 14: TSEC 0 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 15: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 16: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 17: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 18: TSEC 0 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 19: TSEC 1 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 20: TSEC 1 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 21: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 22: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 23: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 24: TSEC 1 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 25: Fast Ethernet */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 26: DUART */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 27: I2C */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 28: Performance Monitor */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 29: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 30: CPM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 31: Unused */
+ MPC85XX_INTERNAL_IRQ_SENSES,
0x0, /* External 0: */
0x0, /* External 1: */
#if defined(CONFIG_PCI)
@@ -159,7 +127,7 @@ sbc8560_init_IRQ(void)
/* Skip reserved space and internal sources */
openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
/* Map PIC IRQs 0-11 */
- openpic_set_sources(32, 12, OpenPIC_Addr + 0x10000);
+ openpic_set_sources(48, 12, OpenPIC_Addr + 0x10000);
/* we let openpic interrupts starting from an offset, to
* leave space for cascading interrupts underneath.
diff --git a/arch/ppc/platforms/85xx/stx_gp3.c b/arch/ppc/platforms/85xx/stx_gp3.c
--- a/arch/ppc/platforms/85xx/stx_gp3.c
+++ b/arch/ppc/platforms/85xx/stx_gp3.c
@@ -72,38 +72,7 @@ unsigned long pci_dram_offset = 0;
/* Internal interrupts are all Level Sensitive, and Positive Polarity */
static u8 gp3_openpic_initsenses[] __initdata = {
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 0: L2 Cache */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 1: ECM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 2: DDR DRAM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 3: LBIU */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 4: DMA 0 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 5: DMA 1 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 6: DMA 2 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 7: DMA 3 */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 8: PCI/PCI-X */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 9: RIO Inbound Port Write Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 10: RIO Doorbell Inbound */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 11: RIO Outbound Message */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 12: RIO Inbound Message */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 13: TSEC 0 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 14: TSEC 0 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 15: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 16: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 17: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 18: TSEC 0 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 19: TSEC 1 Transmit */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 20: TSEC 1 Receive */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 21: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 22: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 23: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 24: TSEC 1 Receive/Transmit Error */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 25: Fast Ethernet */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 26: DUART */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 27: I2C */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 28: Performance Monitor */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 29: Unused */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 30: CPM */
- (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 31: Unused */
+ MPC85XX_INTERNAL_IRQ_SENSES,
0x0, /* External 0: */
#if defined(CONFIG_PCI)
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 1: PCI slot 0 */
@@ -200,7 +169,6 @@ static struct irqaction cpm2_irqaction =
static void __init
gp3_init_IRQ(void)
{
- int i;
bd_t *binfo = (bd_t *) __res;
/*
@@ -218,7 +186,7 @@ gp3_init_IRQ(void)
openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
/* Map PIC IRQs 0-11 */
- openpic_set_sources(32, 12, OpenPIC_Addr + 0x10000);
+ openpic_set_sources(48, 12, OpenPIC_Addr + 0x10000);
/*
* Let openpic interrupts starting from an offset, to
diff --git a/include/asm-ppc/irq.h b/include/asm-ppc/irq.h
--- a/include/asm-ppc/irq.h
+++ b/include/asm-ppc/irq.h
@@ -176,7 +176,7 @@ static __inline__ int irq_canonicalize(i
*/
#include <asm/mpc85xx.h>
-/* The MPC8560 openpic has 32 internal interrupts and 12 external
+/* The MPC8548 openpic has 48 internal interrupts and 12 external
* interrupts.
*
* We are "flattening" the interrupt vectors of the cascaded CPM
@@ -184,7 +184,7 @@ static __inline__ int irq_canonicalize(i
* single integer.
*/
#define NR_CPM_INTS 64
-#define NR_EPIC_INTS 44
+#define NR_EPIC_INTS 60
#ifndef NR_8259_INTS
#define NR_8259_INTS 0
#endif
@@ -241,18 +241,18 @@ static __inline__ int irq_canonicalize(i
#define MPC85xx_IRQ_CPM (30 + MPC85xx_OPENPIC_IRQ_OFFSET)
/* The 12 external interrupt lines */
-#define MPC85xx_IRQ_EXT0 (32 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT1 (33 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT2 (34 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT3 (35 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT4 (36 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT5 (37 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT6 (38 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT7 (39 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT8 (40 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT9 (41 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT10 (42 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT11 (43 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT0 (48 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT1 (49 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT2 (50 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT3 (51 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT4 (52 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT5 (53 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT6 (54 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT7 (55 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT8 (56 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT9 (57 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT10 (58 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT11 (59 + MPC85xx_OPENPIC_IRQ_OFFSET)
/* CPM related interrupts */
#define SIU_INT_ERROR ((uint)0x00+CPM_IRQ_OFFSET)
diff --git a/include/asm-ppc/mpc85xx.h b/include/asm-ppc/mpc85xx.h
--- a/include/asm-ppc/mpc85xx.h
+++ b/include/asm-ppc/mpc85xx.h
@@ -134,6 +134,57 @@ enum ppc_sys_devices {
MPC85xx_IIC2,
};
+/* Internal interrupts are all Level Sensitive, and Positive Polarity */
+#define MPC85XX_INTERNAL_IRQ_SENSES \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 0 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 1 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 2 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 3 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 4 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 5 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 6 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 7 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 8 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 9 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 10 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 11 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 12 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 13 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 14 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 15 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 16 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 17 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 18 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 19 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 20 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 21 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 22 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 23 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 24 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 25 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 26 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 27 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 28 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 29 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 30 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 31 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 32 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 33 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 34 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 35 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 36 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 37 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 38 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 39 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 40 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 41 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 42 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 43 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 44 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 45 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE), /* Internal 46 */ \
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_POSITIVE) /* Internal 47 */
+
#endif /* CONFIG_85xx */
#endif /* __ASM_MPC85xx_H__ */
#endif /* __KERNEL__ */
^ permalink raw reply
* [PATCH] ppc32: Clean up NUM_TLBCAMS usage for Freescale Book-E PPC's
From: Kumar Gala @ 2005-06-09 5:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Made the number of TLB CAM entries private and converted the board consumers
to use num_tlbcam_entries which is setup at boot time from configuration
registers. This way the only consumers of the #define NUM_TLBCAMS are the
arrays used to manage the TLB.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 24e4731a8b0b74af65f39fa11cc3a520e52f0a63
tree 89a18636e8eab485757cb89ee0645bc3ca27f1de
parent d754db8e39a79ae9a159f747511889647e46748a
author Kumar K. Gala <kumar.gala@freescale.com> Thu, 09 Jun 2005 00:41:46 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 09 Jun 2005 00:41:46 -0500
arch/ppc/mm/fsl_booke_mmu.c | 2 ++
arch/ppc/mm/mmu_decl.h | 2 ++
arch/ppc/mm/pgtable.c | 1 -
arch/ppc/platforms/85xx/mpc8540_ads.c | 4 ++--
arch/ppc/platforms/85xx/mpc85xx_cds_common.c | 4 ++--
arch/ppc/platforms/85xx/sbc8560.c | 4 ++--
include/asm-ppc/pgtable.h | 2 --
7 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/ppc/mm/fsl_booke_mmu.c b/arch/ppc/mm/fsl_booke_mmu.c
--- a/arch/ppc/mm/fsl_booke_mmu.c
+++ b/arch/ppc/mm/fsl_booke_mmu.c
@@ -64,6 +64,8 @@ extern unsigned long total_lowmem;
extern unsigned long __max_low_memory;
#define MAX_LOW_MEM CONFIG_LOWMEM_SIZE
+#define NUM_TLBCAMS (16)
+
struct tlbcam {
u32 MAS0;
u32 MAS1;
diff --git a/arch/ppc/mm/mmu_decl.h b/arch/ppc/mm/mmu_decl.h
--- a/arch/ppc/mm/mmu_decl.h
+++ b/arch/ppc/mm/mmu_decl.h
@@ -43,6 +43,8 @@ extern int mem_init_done;
extern PTE *Hash, *Hash_end;
extern unsigned long Hash_size, Hash_mask;
+extern unsigned int num_tlbcam_entries;
+
/* ...and now those things that may be slightly different between processor
* architectures. -- Dan
*/
diff --git a/arch/ppc/mm/pgtable.c b/arch/ppc/mm/pgtable.c
--- a/arch/ppc/mm/pgtable.c
+++ b/arch/ppc/mm/pgtable.c
@@ -66,7 +66,6 @@ void setbat(int index, unsigned long vir
#ifdef HAVE_TLBCAM
extern unsigned int tlbcam_index;
-extern unsigned int num_tlbcam_entries;
extern unsigned long v_mapped_by_tlbcam(unsigned long va);
extern unsigned long p_mapped_by_tlbcam(unsigned long pa);
#else /* !HAVE_TLBCAM */
diff --git a/arch/ppc/platforms/85xx/mpc8540_ads.c b/arch/ppc/platforms/85xx/mpc8540_ads.c
--- a/arch/ppc/platforms/85xx/mpc8540_ads.c
+++ b/arch/ppc/platforms/85xx/mpc8540_ads.c
@@ -88,7 +88,7 @@ mpc8540ads_setup_arch(void)
#ifdef CONFIG_SERIAL_TEXT_DEBUG
/* Invalidate the entry we stole earlier the serial ports
* should be properly mapped */
- invalidate_tlbcam_entry(NUM_TLBCAMS - 1);
+ invalidate_tlbcam_entry(num_tlbcam_entries - 1);
#endif
/* setup the board related information for the enet controllers */
@@ -150,7 +150,7 @@ platform_init(unsigned long r3, unsigned
struct uart_port p;
/* Use the last TLB entry to map CCSRBAR to allow access to DUART regs */
- settlbcam(NUM_TLBCAMS - 1, binfo->bi_immr_base,
+ settlbcam(num_tlbcam_entries - 1, binfo->bi_immr_base,
binfo->bi_immr_base, MPC85xx_CCSRBAR_SIZE, _PAGE_IO, 0);
memset(&p, 0, sizeof (p));
diff --git a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
@@ -446,7 +446,7 @@ mpc85xx_cds_setup_arch(void)
#ifdef CONFIG_SERIAL_TEXT_DEBUG
/* Invalidate the entry we stole earlier the serial ports
* should be properly mapped */
- invalidate_tlbcam_entry(NUM_TLBCAMS - 1);
+ invalidate_tlbcam_entry(num_tlbcam_entries - 1);
#endif
/* setup the board related information for the enet controllers */
@@ -528,7 +528,7 @@ platform_init(unsigned long r3, unsigned
struct uart_port p;
/* Use the last TLB entry to map CCSRBAR to allow access to DUART regs */
- settlbcam(NUM_TLBCAMS - 1, binfo->bi_immr_base,
+ settlbcam(num_tlbcam_entries - 1, binfo->bi_immr_base,
binfo->bi_immr_base, MPC85xx_CCSRBAR_SIZE, _PAGE_IO, 0);
memset(&p, 0, sizeof (p));
diff --git a/arch/ppc/platforms/85xx/sbc8560.c b/arch/ppc/platforms/85xx/sbc8560.c
--- a/arch/ppc/platforms/85xx/sbc8560.c
+++ b/arch/ppc/platforms/85xx/sbc8560.c
@@ -125,7 +125,7 @@ sbc8560_setup_arch(void)
#ifdef CONFIG_SERIAL_TEXT_DEBUG
/* Invalidate the entry we stole earlier the serial ports
* should be properly mapped */
- invalidate_tlbcam_entry(NUM_TLBCAMS - 1);
+ invalidate_tlbcam_entry(num_tlbcam_entries - 1);
#endif
/* setup the board related information for the enet controllers */
@@ -176,7 +176,7 @@ platform_init(unsigned long r3, unsigned
#ifdef CONFIG_SERIAL_TEXT_DEBUG
/* Use the last TLB entry to map CCSRBAR to allow access to DUART regs */
- settlbcam(NUM_TLBCAMS - 1, UARTA_ADDR,
+ settlbcam(num_tlbcam_entries - 1, UARTA_ADDR,
UARTA_ADDR, 0x1000, _PAGE_IO, 0);
#endif
diff --git a/include/asm-ppc/pgtable.h b/include/asm-ppc/pgtable.h
--- a/include/asm-ppc/pgtable.h
+++ b/include/asm-ppc/pgtable.h
@@ -267,8 +267,6 @@ extern unsigned long ioremap_bot, iorema
#define _PMD_PRESENT_MASK (PAGE_MASK)
#define _PMD_BAD (~PAGE_MASK)
-#define NUM_TLBCAMS (16)
-
#elif defined(CONFIG_8xx)
/* Definitions for 8xx embedded chips. */
#define _PAGE_PRESENT 0x0001 /* Page is valid */
^ permalink raw reply
* Re: consistent_alloc() on 82xx
From: Pantelis Antoniou @ 2005-06-09 6:15 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <d32482ab845e745a00426671eff86b9e@embeddededge.com>
Dan Malek wrote:
>
> On Jun 8, 2005, at 5:29 AM, Alex Zeffertt wrote:
>
>> Does anybody know why it isn't built for 6xx cores?
>
>
> Because 6xx cores are cache coherent and there shouldn't
> be any need for "uncached" memory regions.
>
>> I'm working on the ATM driver and it seems that certain external memory
>> areas accessed by the PQII CPM by-pass the cache.
>
>
> That's news to me, and I've written lots of CPM drivers, including ATM.
> Do you have a specific example?
>
I may also need consistent_alloc for some testing reasons Dan. :)
> Thanks.
>
> -- Dan
>
If I build arch/ppc/mm/cachemap.c will it work for 82xx? Any reason not to?
Regards
Pantelis
^ permalink raw reply
* Read in /dev/port with Segmentation Fault
From: scarayol @ 2005-06-09 7:30 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I want to access to IO ports on a MPC885. The iopl() is not implemented, in
my distribution, to use inw() outw().
So I use /dev/port. It works for open("/dev/port",..) and lseek() but when
i do a read() i have a segmentation fault. I gave all the right to
/dev/port
Does anybody have an idea ?
Thanks a lot.
Sophie CARAYOL
^ permalink raw reply
* Re: consistent_alloc() on 82xx
From: Alex Zeffertt @ 2005-06-09 9:04 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <d32482ab845e745a00426671eff86b9e@embeddededge.com>
On Wed, 8 Jun 2005 12:12:01 -0400
Dan Malek <dan@embeddededge.com> wrote:
>
> On Jun 8, 2005, at 5:29 AM, Alex Zeffertt wrote:
>
> > Does anybody know why it isn't built for 6xx cores?
>
> Because 6xx cores are cache coherent and there shouldn't
> be any need for "uncached" memory regions.
>
> > I'm working on the ATM driver and it seems that certain external
> > memory areas accessed by the PQII CPM by-pass the cache.
>
> That's news to me, and I've written lots of CPM drivers, including
> ATM. Do you have a specific example?
>
Hi Dan,
An example of non-cache coherency in the CPM2: In the ATM chapter of
the 8260 UM it says that the CPM will only assert GBL and "snoop"
buffers, Buffer Descriptors, and interrupt queues if you set TCT[GBL]
and RCT[GBL]. Presumably this means that it *does not* by-pass the
cache if this flag is not set. More seriously, for address compression
tables, and external connection tables there is no way of specifying
that it *should* snoop - (which I assume means "use the cache").
I have seen this causing problems. When I map a VPI/VCI to a connection
table using the address compression table, the first few cells received
do NOT get mapped. I thought this might be a result of the CPM
by-passing the cache so I added a "flush_dcache_range" after writing to
the address compression tables. When I did this the problem went away.
With external connection tables the problem is more severe. During
frame transmission, the core is constantly having to read and write to
the Transmit Connection Table in order to use Auto-VC-ofF. I couldn't
get this to work until I added lots of "invalidate_dcache_range" and
"flush_dcache_range" calls. However, doing this is (i) inefficient, and
(ii) *very* error prone.
Alex
^ permalink raw reply
* Re: consistent_alloc() on 82xx
From: Alex Zeffertt @ 2005-06-09 9:06 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <42A7DE75.8040205@intracom.gr>
On Thu, 09 Jun 2005 09:15:17 +0300
Pantelis Antoniou <panto@intracom.gr> wrote:
> Dan Malek wrote:
> >
> > On Jun 8, 2005, at 5:29 AM, Alex Zeffertt wrote:
> >
> >> Does anybody know why it isn't built for 6xx cores?
> >
> >
> > Because 6xx cores are cache coherent and there shouldn't
> > be any need for "uncached" memory regions.
> >
> >> I'm working on the ATM driver and it seems that certain external
> >memory> areas accessed by the PQII CPM by-pass the cache.
> >
> >
> > That's news to me, and I've written lots of CPM drivers, including
> > ATM. Do you have a specific example?
> >
>
> I may also need consistent_alloc for some testing reasons Dan. :)
>
> > Thanks.
> >
> > -- Dan
> >
>
> If I build arch/ppc/mm/cachemap.c will it work for 82xx? Any reason
> not to?
>
Hi Pantelis,
I tried this in an attempt to work around my problem of the CPM
bypassing the cache but it didn't work for me....
Alex
^ permalink raw reply
* Re: Read in /dev/port with Segmentation Fault
From: Matt Porter @ 2005-06-09 9:12 UTC (permalink / raw)
To: scarayol; +Cc: linuxppc-embedded
In-Reply-To: <OF76EEFE38.5001E643-ONC125701B.00283639@brime.fr>
On Thu, Jun 09, 2005 at 09:30:43AM +0200, scarayol@assystembrime.com wrote:
> Hi all,
>
> I want to access to IO ports on a MPC885. The iopl() is not implemented, in
> my distribution, to use inw() outw().
> So I use /dev/port. It works for open("/dev/port",..) and lseek() but when
> i do a read() i have a segmentation fault. I gave all the right to
> /dev/port
> Does anybody have an idea ?
You are trying to use x86-specific interfaces to x86-specific IO space.
By "IO ports" you must mean memory mapped I/O registers since you are
on PPC. From userspace, use mmap() to map physical address space to a
user virtual address range.
-Matt
^ permalink raw reply
* Réf. : Re: Read in /dev/port with Segmentation Fault
From: scarayol @ 2005-06-09 9:30 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
Matt,
then what is the use of /dev/port driver file ? When i do "cat /dev/port"
on the standard console, i have also a segmentation fault.
Another question, if i use mmap to map physical addresses of I/O registers,
could i dereference the pointer on virtual adresse to access data or should
i use read/write on the file descriptor ?
Best regards.
Sophie CARAYOL
Matt Porter
<mporter@kernel.cra Pour : scarayol@assystembrime.com
shing.org> cc : linuxppc-embedded@ozlabs.org
Objet : Re: Read in /dev/port with Segmentation Fault
09/06/05 11:12
On Thu, Jun 09, 2005 at 09:30:43AM +0200, scarayol@assystembrime.com wrote:
> Hi all,
>
> I want to access to IO ports on a MPC885. The iopl() is not implemented,
in
> my distribution, to use inw() outw().
> So I use /dev/port. It works for open("/dev/port",..) and lseek() but
when
> i do a read() i have a segmentation fault. I gave all the right to
> /dev/port
> Does anybody have an idea ?
You are trying to use x86-specific interfaces to x86-specific IO space.
By "IO ports" you must mean memory mapped I/O registers since you are
on PPC. From userspace, use mmap() to map physical address space to a
user virtual address range.
-Matt
^ permalink raw reply
* RE : PPC arch and spinlocks
From: Garcia Jérémie @ 2005-06-09 9:28 UTC (permalink / raw)
To: jeff; +Cc: linuxppc-dev
First of all,tks Jeff for this link.=20
So reading that, I understood that I need to enable the SMP support in =
the makemenuconfig
in order to use spinlocks even if I'm working on UP platform.
That's what I did but I now go through compile errors (I'm using a =
montavista PE 3.1):
In file included from =
/myWorks/en-cours/linux-2.4.20_mvl31/include/linux/smp.h:14,
from ppc4xx_setup.c:34:
/myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:28: error: =
`NR_CPUS' undeclared here (not in a function)
/myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:30: error: =
`NR_CPUS' undeclared here (not in a function)
/myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:31: error: =
`NR_CPUS' undeclared here (not in a function)
/myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:31: embrouill=E9 =
par les erreurs pr=E9c=E9dentes, abandon
make[1]: *** [ppc4xx_setup.o] Erreur 1
make[1]: Quitte le r=E9pertoire =
`/myWorks/en-cours/linux-2.4.20_mvl31/arch/ppc/kernel'
make: *** [_dir_arch/ppc/kernel] Erreur 2
Is it a known problem for the montavista ppc users??
-------- Message d'origine--------
De: Jeff Angielski [mailto:jeff@theptrgroup.com]
Date: mer. 08/06/2005 17:26
=C0: Garcia J=E9r=E9mie
Cc: linuxppc-dev@ozlabs.org
Objet : Re: PPC arch and spinlocks
=20
On Wed, 2005-06-08 at 16:29 +0200, Garcia J=E9r=E9mie wrote:
> Hi everybody, I need your help one more time.
> I'm new to kernel device driver (linux newbie) and I'd like to control =
concurrent access
> to our hardware resources. (I'm working on a ppc405EP platform =
uniprocessor)
You might find this guide useful:
http://www.kernelnewbies.org/documents/kdoc/kernel-locking/lklockingguide=
.html
Jeff Angielski
The PTR Group
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox