* Re: gdb hangs on Linux 2.6.11 on 8xx
From: Aristeu Sergio Rozanski Filho @ 2005-09-13 12:25 UTC (permalink / raw)
To: Chris; +Cc: linuxppc-embedded
In-Reply-To: <4326968F.5030609@2net.co.uk>
> I am running Linux 2.6.11 on a TQM823L development board. I find that
> gdb (version 6.3) hangs when I try to run an application - any
> application, even a simple helloworld. It's not just gdb hanging, the
> whole system is stone dead.
"me too"
actually the system is not completely dead, you still can use sysrq keys.
Tried to use gdbserver too, but it also doesn't work (hangs after the first
breakpoint and timeouts).
gdb S 30106778 0 691 687 692 (NOTLB)
Call trace:
[c0005330] __switch_to+0x44/0x78
[c015beb0] schedule+0x30c/0x730
[c015c888] schedule_timeout+0xdc/0xe0
[c0068918] sys_poll+0x27c/0x404
[c0002810] syscall_dotrace_cont+0x24/0x38
flash_test t 100009E4 0 692 691 (NOTLB)
Call trace:
[c0005330] __switch_to+0x44/0x78
[c015beb0] schedule+0x30c/0x730
[c0026248] ptrace_stop+0x68/0x88
[c0026604] get_signal_to_deliver+0x130/0x2b4
[c00063dc] do_signal+0x38/0x464
[c0003034] do_user_signal+0x74/0xc4
--
Aristeu
^ permalink raw reply
* Regarding booting the PPC board - issue with Ramdisk
From: vinay hegde @ 2005-09-13 12:57 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
Hi ,
I am trying to bring up the linux 2.6 on mvme6100
(ppc) board. But, when I boot the board with the
kernel image, it fails with the following error
message:
>>>>>>>
RAMDISK: Couldn't find valid RAM disk image starting
at 0.
Kernel panic: VFS: Unable to mount root fs on ram1
>>>>>>>
I am not able to understand what is going wrong here.
The image is comprised of compressed kernel image and
RFS.
Can somebody help me in this regard?
I have attached the output that I get when I boot the
board aong with this mail.
Thank you,
Vinay
__________________________________________________________
Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com
[-- Attachment #2: 3147179390-log.sxw --]
[-- Type: application/vnd.sun.xml.writer, Size: 7009 bytes --]
^ permalink raw reply
* Re: gdb hangs on Linux 2.6.11 on 8xx
From: Chris @ 2005-09-13 14:15 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-embedded
In-Reply-To: <20050913122541.GB9076@cathedrallabs.org>
Aristeu Sergio Rozanski Filho wrote:
>>I am running Linux 2.6.11 on a TQM823L development board. I find that
>>gdb (version 6.3) hangs when I try to run an application - any
>>application, even a simple helloworld. It's not just gdb hanging, the
>>whole system is stone dead.
>
> "me too"
> actually the system is not completely dead, you still can use sysrq keys.
> Tried to use gdbserver too, but it also doesn't work (hangs after the first
> breakpoint and timeouts).
>
> gdb S 30106778 0 691 687 692 (NOTLB)
> Call trace:
> [c0005330] __switch_to+0x44/0x78
> [c015beb0] schedule+0x30c/0x730
> [c015c888] schedule_timeout+0xdc/0xe0
> [c0068918] sys_poll+0x27c/0x404
> [c0002810] syscall_dotrace_cont+0x24/0x38
> flash_test t 100009E4 0 692 691 (NOTLB)
> Call trace:
> [c0005330] __switch_to+0x44/0x78
> [c015beb0] schedule+0x30c/0x730
> [c0026248] ptrace_stop+0x68/0x88
> [c0026604] get_signal_to_deliver+0x130/0x2b4
> [c00063dc] do_signal+0x38/0x464
> [c0003034] do_user_signal+0x74/0xc4
>
Good to know that it's not just me... As you point out it's not
completely dead. A register dump shows the following:
SysRq : Show Regs
NIP: C00047BC LR: C000A0C0 SP: C09FBDD0 REGS: c09fbd20 TRAP: 0501 Not
tainted
MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
TASK = c031f3e0[187] 'gdb' THREAD: c09fa000
Last syscall: 26
GPR00: 00009022 C09FBDD0 C031F3E0 00589000 00000100 C01F3000 00588000
808B0000
GPR08: 38600000 C01D0000 00009032 0000B100 33003035
NIP [c00047bc] __flush_dcache_icache_phys+0x38/0x54
LR [c000a0c0] flush_dcache_icache_page+0x20/0x30
Call trace:
[c000a17c] update_mmu_cache+0x68/0x98
[c003dbe8] do_wp_page+0x184/0x3a4
[c003ebc8] handle_mm_fault+0x29c/0x42c
[c003ee7c] get_user_pages+0x124/0x428
[c001a030] access_process_vm+0xfc/0x1bc
[c0006680] sys_ptrace+0x22c/0x4b4
[c0002590] ret_from_syscall+0x0/0x44
Which looks like the call to ptrace caused a page fault, after which it
to stopped in __flush_dcache_icache_phys for some reason. Maybe some
serious digging is needed after all.
Chris.
^ permalink raw reply
* Re: gdb hangs on Linux 2.6.11 on 8xx
From: Marcelo Tosatti @ 2005-09-13 14:25 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-embedded
In-Reply-To: <20050913122541.GB9076@cathedrallabs.org>
Folks,
Can you please upgrade to a recent kernel?
A problem with ptrace has been fixed sometime ago, it might be what you're hitting.
The fix is part of v2.6.13:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bf85fa6c878aa3968df47d7f70a2b506c3e53b99
If that does not work, complain.
On Tue, Sep 13, 2005 at 09:25:41AM -0300, Aristeu Sergio Rozanski Filho wrote:
> > I am running Linux 2.6.11 on a TQM823L development board. I find that
> > gdb (version 6.3) hangs when I try to run an application - any
> > application, even a simple helloworld. It's not just gdb hanging, the
> > whole system is stone dead.
> "me too"
> actually the system is not completely dead, you still can use sysrq keys.
> Tried to use gdbserver too, but it also doesn't work (hangs after the first
> breakpoint and timeouts).
>
> gdb S 30106778 0 691 687 692 (NOTLB)
> Call trace:
> [c0005330] __switch_to+0x44/0x78
> [c015beb0] schedule+0x30c/0x730
> [c015c888] schedule_timeout+0xdc/0xe0
> [c0068918] sys_poll+0x27c/0x404
> [c0002810] syscall_dotrace_cont+0x24/0x38
> flash_test t 100009E4 0 692 691 (NOTLB)
> Call trace:
> [c0005330] __switch_to+0x44/0x78
> [c015beb0] schedule+0x30c/0x730
> [c0026248] ptrace_stop+0x68/0x88
> [c0026604] get_signal_to_deliver+0x130/0x2b4
> [c00063dc] do_signal+0x38/0x464
> [c0003034] do_user_signal+0x74/0xc4
>
> --
> Aristeu
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: USB root filesytem using a 2.6 kernel?
From: Peter Korsgaard @ 2005-09-13 14:34 UTC (permalink / raw)
To: Jeff Stevens; +Cc: linuxppc-embedded
In-Reply-To: <20050913121748.66647.qmail@web33013.mail.mud.yahoo.com>
On 9/13/05, Jeff Stevens <jsteve17@yahoo.com> wrote:
> Has anyone had any luck booting from a linux filesytem
> on a USB pen drive running 2.6?
It's a timing issue - your USB stick doesn't get detected / scanned
for partitions before the kernel tries to mount the rootfs. Use the
rootdelay kernel parameter to force a delay (of E.G. 10s) to fix it.
You might need to upgrade your kernel through, I think it was added in 2.6.=
11
--=20
Bye, Peter Korsgaard
^ permalink raw reply
* Re: gdb hangs on Linux 2.6.11 on 8xx
From: Aristeu Sergio Rozanski Filho @ 2005-09-13 14:51 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20050913142513.GD10602@dmt.cnet>
> Can you please upgrade to a recent kernel?
>
> A problem with ptrace has been fixed sometime ago, it might be what you're hitting.
>
> The fix is part of v2.6.13:
>
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bf85fa6c878aa3968df47d7f70a2b506c3e53b99
>
> If that does not work, complain.
sorry, but it's a 2.6.10 with this patch applied and I did test with
2.6.13 kernel. I'll re-test with current Linus tree.
--
Aristeu
^ permalink raw reply
* Re: gdb hangs on Linux 2.6.11 on 8xx
From: Marcelo Tosatti @ 2005-09-13 15:11 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-embedded
In-Reply-To: <20050913122541.GB9076@cathedrallabs.org>
On Tue, Sep 13, 2005 at 09:25:41AM -0300, Aristeu Sergio Rozanski Filho wrote:
> > I am running Linux 2.6.11 on a TQM823L development board. I find that
> > gdb (version 6.3) hangs when I try to run an application - any
> > application, even a simple helloworld. It's not just gdb hanging, the
> > whole system is stone dead.
> "me too"
> actually the system is not completely dead, you still can use sysrq keys.
> Tried to use gdbserver too, but it also doesn't work (hangs after the first
> breakpoint and timeouts).
>
> gdb S 30106778 0 691 687 692 (NOTLB)
> Call trace:
> [c0005330] __switch_to+0x44/0x78
> [c015beb0] schedule+0x30c/0x730
> [c015c888] schedule_timeout+0xdc/0xe0
> [c0068918] sys_poll+0x27c/0x404
> [c0002810] syscall_dotrace_cont+0x24/0x38
> flash_test t 100009E4 0 692 691 (NOTLB)
> Call trace:
> [c0005330] __switch_to+0x44/0x78
> [c015beb0] schedule+0x30c/0x730
> [c0026248] ptrace_stop+0x68/0x88
> [c0026604] get_signal_to_deliver+0x130/0x2b4
> [c00063dc] do_signal+0x38/0x464
> [c0003034] do_user_signal+0x74/0xc4
Aris,
How does the disassemble of __switch_to looks like?
Chris oopsen is exactly what the 'icbi' patch fixes.
Maybe this is an additional problem then.
SysRq : Show Regs
NIP: C00047BC LR: C000A0C0 SP: C09FBDD0 REGS: c09fbd20 TRAP: 0501 Not
tainted
MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
TASK = c031f3e0[187] 'gdb' THREAD: c09fa000
Last syscall: 26
GPR00: 00009022 C09FBDD0 C031F3E0 00589000 00000100 C01F3000 00588000
808B0000
GPR08: 38600000 C01D0000 00009032 0000B100 33003035
NIP [c00047bc] __flush_dcache_icache_phys+0x38/0x54
LR [c000a0c0] flush_dcache_icache_page+0x20/0x30
Call trace:
[c000a17c] update_mmu_cache+0x68/0x98
[c003dbe8] do_wp_page+0x184/0x3a4
[c003ebc8] handle_mm_fault+0x29c/0x42c
[c003ee7c] get_user_pages+0x124/0x428
[c001a030] access_process_vm+0xfc/0x1bc
[c0006680] sys_ptrace+0x22c/0x4b4
[c0002590] ret_from_syscall+0x0/0x44
^ permalink raw reply
* Re: gdb hangs on Linux 2.6.11 on 8xx
From: Chris @ 2005-09-13 16:27 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050913142513.GD10602@dmt.cnet>
Marcelo Tosatti wrote:
> Folks,
>
> Can you please upgrade to a recent kernel?
>
> A problem with ptrace has been fixed sometime ago, it might be what you're hitting.
>
> The fix is part of v2.6.13:
>
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bf85fa6c878aa3968df47d7f70a2b506c3e53b99
>
> If that does not work, complain.
>
OK, that works. Gdb and gdbserver behave as they should.
Thanks,
Chris.
^ permalink raw reply
* Re: PATCH Merge kmap_types.h
From: Jon Loeliger @ 2005-09-13 16:42 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, linuxppc64-dev
In-Reply-To: <1126039905.25148.66.camel@cashmere.sps.mot.com>
On Tue, 2005-09-06 at 15:51, Jon Loeliger wrote:
> Here is a patch to merge the ppc and pp64 version of kmap_types.h
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
> ---
Paul,
Any reason why this patch for merging kmap_types.h
keeps slipping through cracks? Is it not applying
or something like that? Some merge issue I'm missing?
Thanks,
jdl
^ permalink raw reply
* Merge Question on asm-ppc*/rwsem.h
From: Jon Loeliger @ 2005-09-13 17:06 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, linuxppc64-dev
Paul (or anyone, really),
I am not too familiar with some of the low-level machine
details that might (do!) influence some of the semaphore
implementations. I was hoping I might get you to give
me a quick nudge in the right direction here.
Here is a brief example of the differences found in
the ppc and pp64 versions of asm-ppc*/rwsem.h:
(ppc is -, and ppc64 is + here)
@@ -69,9 +74,7 @@
*/
static inline void __down_read(struct rw_semaphore *sem)
{
- if (atomic_inc_return((atomic_t *)(&sem->count)) > 0)
- smp_wmb();
- else
+ if (unlikely(atomic_inc_return((atomic_t *)(&sem->count)) <= 0))
rwsem_down_read_failed(sem);
}
If we add likely() to the PPC version, and then invert it,
we can get effectively this:
static inline void __down_read(struct rw_semaphore *sem)
{
if (unlikely(atomic_inc_return((atomic_t *)(&sem->count)) <= 0))
rwsem_down_read_failed(sem);
#ifndef __powerpc64__
else
smp_wmb();
#endif
}
Which begs the question, what is the "else smp_wmb();" clause
really doing for us in the ppc32 case, and can we either
get rid of it, or is it safe to add to the ppc64 case?
Thanks,
jdl
^ permalink raw reply
* __switch_to test-and-branch ALTIVEC specific?
From: Marcelo Tosatti @ 2005-09-13 17:50 UTC (permalink / raw)
To: linuxppc-dev, linux-ppc-embedded
Hi,
This test&branch looks AltiVec specific, any reason for not #ifdef'ing it
out?
--- arch/ppc/kernel/process.c.orig 2005-09-13 14:43:13.000000000 -0300
+++ arch/ppc/kernel/process.c 2005-09-13 14:43:51.000000000 -0300
@@ -287,11 +287,13 @@ struct task_struct *__switch_to(struct t
#endif /* CONFIG_SPE */
#endif /* CONFIG_SMP */
+#ifdef CONFIG_ALTIVEC
/* Avoid the trap. On smp this this never happens since
* we don't set last_task_used_altivec -- Cort
*/
if (new->thread.regs && last_task_used_altivec == new)
new->thread.regs->msr |= MSR_VEC;
+#endif
#ifdef CONFIG_SPE
/* Avoid the trap. On smp this this never happens since
* we don't set last_task_used_spe
^ permalink raw reply
* Re: gdb hangs on Linux 2.6.11 on 8xx
From: Aristeu Sergio Rozanski Filho @ 2005-09-13 17:22 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20050913151132.GF10602@dmt.cnet>
Hi Marcelo,
after the last Chris post, I decided to double check if I wasn't doing
something wrong. vanilla 2.6.13 hangs in the same way my patched 2.6.10 does.
> How does the disassemble of __switch_to looks like?
from 2.6.13 kernel
Dump of assembler code for function __switch_to:
0xc00055a4 <__switch_to+0>: mflr r0
0xc00055a8 <__switch_to+4>: stwu r1,-16(r1)
0xc00055ac <__switch_to+8>: stw r31,12(r1)
0xc00055b0 <__switch_to+12>: mr r11,r4
0xc00055b4 <__switch_to+16>: stw r0,20(r1)
0xc00055b8 <__switch_to+20>: mfmsr r31
0xc00055bc <__switch_to+24>: rlwinm r0,r31,0,17,15
0xc00055c0 <__switch_to+28>: mtmsr r0
0xc00055c4 <__switch_to+32>: lwz r10,460(r4)
0xc00055c8 <__switch_to+36>: addi r3,r2,456
0xc00055cc <__switch_to+40>: addi r4,r4,456
0xc00055d0 <__switch_to+44>: cmpwi cr7,r10,0
0xc00055d4 <__switch_to+48>: beq- cr7,0xc00055e8 <__switch_to+68>
0xc00055d8 <__switch_to+52>: lis r9,-16354
0xc00055dc <__switch_to+56>: lwz r0,28880(r9)
0xc00055e0 <__switch_to+60>: cmpw cr7,r0,r11
0xc00055e4 <__switch_to+64>: beq- cr7,0xc0005604 <__switch_to+96>
0xc00055e8 <__switch_to+68>: bl 0xc0003024 <_switch>
0xc00055ec <__switch_to+72>: mtmsr r31
0xc00055f0 <__switch_to+76>: lwz r0,20(r1)
0xc00055f4 <__switch_to+80>: lwz r31,12(r1)
0xc00055f8 <__switch_to+84>: addi r1,r1,16
0xc00055fc <__switch_to+88>: mtlr r0
0xc0005600 <__switch_to+92>: blr
0xc0005604 <__switch_to+96>: lwz r0,132(r10)
0xc0005608 <__switch_to+100>: oris r0,r0,512
0xc000560c <__switch_to+104>: stw r0,132(r10)
0xc0005610 <__switch_to+108>: b 0xc00055e8 <__switch_to+68>
End of assembler dump.
> Chris oopsen is exactly what the 'icbi' patch fixes.
notice that what I'm having here is not an oops
but if for Chris works, I must be doing something wrong, sorry for the noise
--
Aristeu
^ permalink raw reply
* Re: gdb hangs on Linux 2.6.11 on 8xx
From: Marcelo Tosatti @ 2005-09-13 18:04 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-embedded
In-Reply-To: <20050913172213.GA3964@oops.ghostprotocols.net>
On Tue, Sep 13, 2005 at 02:22:13PM -0300, Aristeu Sergio Rozanski Filho wrote:
> Hi Marcelo,
> after the last Chris post, I decided to double check if I wasn't doing
> something wrong. vanilla 2.6.13 hangs in the same way my patched 2.6.10 does.
>
> > How does the disassemble of __switch_to looks like?
> from 2.6.13 kernel
> Dump of assembler code for function __switch_to:
> 0xc00055a4 <__switch_to+0>: mflr r0
> 0xc00055a8 <__switch_to+4>: stwu r1,-16(r1)
> 0xc00055ac <__switch_to+8>: stw r31,12(r1)
> 0xc00055b0 <__switch_to+12>: mr r11,r4
> 0xc00055b4 <__switch_to+16>: stw r0,20(r1)
> 0xc00055b8 <__switch_to+20>: mfmsr r31
> 0xc00055bc <__switch_to+24>: rlwinm r0,r31,0,17,15
> 0xc00055c0 <__switch_to+28>: mtmsr r0
> 0xc00055c4 <__switch_to+32>: lwz r10,460(r4)
> 0xc00055c8 <__switch_to+36>: addi r3,r2,456
> 0xc00055cc <__switch_to+40>: addi r4,r4,456
> 0xc00055d0 <__switch_to+44>: cmpwi cr7,r10,0
> 0xc00055d4 <__switch_to+48>: beq- cr7,0xc00055e8 <__switch_to+68>
> 0xc00055d8 <__switch_to+52>: lis r9,-16354
> 0xc00055dc <__switch_to+56>: lwz r0,28880(r9)
> 0xc00055e0 <__switch_to+60>: cmpw cr7,r0,r11
> 0xc00055e4 <__switch_to+64>: beq- cr7,0xc0005604 <__switch_to+96>
> 0xc00055e8 <__switch_to+68>: bl 0xc0003024 <_switch>
> 0xc00055ec <__switch_to+72>: mtmsr r31
> 0xc00055f0 <__switch_to+76>: lwz r0,20(r1)
> 0xc00055f4 <__switch_to+80>: lwz r31,12(r1)
> 0xc00055f8 <__switch_to+84>: addi r1,r1,16
> 0xc00055fc <__switch_to+88>: mtlr r0
> 0xc0005600 <__switch_to+92>: blr
> 0xc0005604 <__switch_to+96>: lwz r0,132(r10)
> 0xc0005608 <__switch_to+100>: oris r0,r0,512
> 0xc000560c <__switch_to+104>: stw r0,132(r10)
> 0xc0005610 <__switch_to+108>: b 0xc00055e8 <__switch_to+68>
> End of assembler dump.
>
> > Chris oopsen is exactly what the 'icbi' patch fixes.
> notice that what I'm having here is not an oops
>
> but if for Chris works, I must be doing something wrong, sorry for the noise
Hi Aris,
gdb S 30106778 0 691 687 692 (NOTLB)
Call trace:
[c0005330] __switch_to+0x44/0x78
[c015beb0] schedule+0x30c/0x730
[c015c888] schedule_timeout+0xdc/0xe0
[c0068918] sys_poll+0x27c/0x404
[c0002810] syscall_dotrace_cont+0x24/0x38
flash_test t 100009E4 0 692 691 (NOTLB)
Call trace:
[c0005330] __switch_to+0x44/0x78
[c015beb0] schedule+0x30c/0x730
[c0026248] ptrace_stop+0x68/0x88
[c0026604] get_signal_to_deliver+0x130/0x2b4
[c00063dc] do_signal+0x38/0x464
[c0003034] do_user_signal+0x74/0xc4
flash_test is trying to handle a signal, can you print some information
about it in get_signal_to_deliver (before ptrace_stop), such as si_signo:
typedef struct siginfo {
int si_signo;
int si_errno;
int si_code;
ptrace_stop() calls do_notify_parent_cldstop() to wakeup gdb, maybe
there's something wrong during wakeup?
The box locks up completly or its just gdb that freezes?
^ permalink raw reply
* [PATCH] ppc32 8xx: use io accessor macros instead of direct memory reference
From: Marcelo Tosatti @ 2005-09-13 17:30 UTC (permalink / raw)
To: torvalds; +Cc: linux-ppc-embedded
Convert core 8xx drivers to use in_xxxbe/in_xxx macros instead
of direct memory references.
Other than making IO accesses explicit (which is a plus for
readability), a common set of macros provides a unified place for the
volatile flag to constraint compiler code reordering.
There are several unlucky places at the moment which lack the
volatile flag.
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -73,7 +73,7 @@ cpm_mask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr &= ~(1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr) & ~(1 << cpm_vec));
}
static void
@@ -81,7 +81,7 @@ cpm_unmask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr |= (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr) | (1 << cpm_vec));
}
static void
@@ -95,7 +95,7 @@ cpm_eoi(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr = (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr, (1 << cpm_vec));
}
struct hw_interrupt_type cpm_pic = {
@@ -133,7 +133,7 @@ m8xx_cpm_reset(void)
* manual recommends it.
* Bit 25, FAM can also be set to use FEC aggressive mode (860T).
*/
- imp->im_siu_conf.sc_sdcr = 1;
+ out_be32(&imp->im_siu_conf.sc_sdcr, 1),
/* Reclaim the DP memory for our use. */
m8xx_cpm_dpinit();
@@ -178,10 +178,10 @@ cpm_interrupt_init(void)
/* Initialize the CPM interrupt controller.
*/
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr =
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr,
(CICR_SCD_SCC4 | CICR_SCC_SCC3 | CICR_SCB_SCC2 | CICR_SCA_SCC1) |
- ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr = 0;
+ ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, 0);
/* install the CPM interrupt controller routines for the CPM
* interrupt vectors
@@ -198,7 +198,7 @@ cpm_interrupt_init(void)
if (setup_irq(CPM_IRQ_OFFSET + CPMVEC_ERROR, &cpm_error_irqaction))
panic("Could not allocate CPM error IRQ!");
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr |= CICR_IEN;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr) | CICR_IEN);
}
/*
@@ -212,8 +212,8 @@ cpm_get_irq(struct pt_regs *regs)
/* Get the vector by setting the ACK bit and then reading
* the register.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr = 1;
- cpm_vec = ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr;
+ out_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr, 1);
+ cpm_vec = in_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr);
cpm_vec >>= 11;
return cpm_vec;
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -144,12 +144,12 @@ void __init m8xx_calibrate_decr(void)
int freq, fp, divisor;
/* Unlock the SCCR. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, KAPWR_KEY);
/* Force all 8xx processors to use divide by 16 processor clock. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrst.car_sccr |= 0x02000000;
-
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_sccr,
+ in_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_sccr)|0x02000000);
/* Processor frequency is MHz.
* The value 'fp' is the number of decrementer ticks per second.
*/
@@ -175,28 +175,24 @@ void __init m8xx_calibrate_decr(void)
* we guarantee the registers are locked, then we unlock them
* for our use.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk = KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk, KAPWR_KEY);
/* Disable the RTC one second and alarm interrupts. */
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc &=
- ~(RTCSC_SIE | RTCSC_ALE);
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc, in_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc) & ~(RTCSC_SIE | RTCSC_ALE));
/* Enable the RTC */
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc |=
- (RTCSC_RTF | RTCSC_RTE);
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc, in_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc) | (RTCSC_RTF | RTCSC_RTE));
/* Enabling the decrementer also enables the timebase interrupts
* (or from the other point of view, to get decrementer interrupts
* we have to enable the timebase). The decrementer interrupt
* is wired into the vector table, nothing to do here for that.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_tbscr =
- ((mk_int_int_mask(DEC_INTERRUPT) << 8) |
- (TBSCR_TBF | TBSCR_TBE));
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_tbscr, (mk_int_int_mask(DEC_INTERRUPT) << 8) | (TBSCR_TBF | TBSCR_TBE));
if (setup_irq(DEC_INTERRUPT, &tbint_irqaction))
panic("Could not allocate timer IRQ!");
@@ -216,9 +212,9 @@ void __init m8xx_calibrate_decr(void)
static int
m8xx_set_rtc_time(unsigned long time)
{
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtc = time;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck = ~KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtc, time);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck, ~KAPWR_KEY);
return(0);
}
@@ -226,7 +222,7 @@ static unsigned long
m8xx_get_rtc_time(void)
{
/* Get time from the RTC. */
- return((unsigned long)(((immap_t *)IMAP_ADDR)->im_sit.sit_rtc));
+ return (unsigned long) in_be32(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtc);
}
static void
@@ -235,13 +231,13 @@ m8xx_restart(char *cmd)
__volatile__ unsigned char dummy;
local_irq_disable();
- ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr |= 0x00000080;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr, in_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr) | 0x00000080);
/* Clear the ME bit in MSR to cause checkstop on machine check
*/
mtmsr(mfmsr() & ~0x1000);
- dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
+ dummy = in_8(&((immap_t *)IMAP_ADDR)->im_clkrst.res[0]);
printk("Restart failed\n");
while(1);
}
@@ -306,8 +302,7 @@ m8xx_init_IRQ(void)
i8259_init(0);
/* The i8259 cascade interrupt must be level sensitive. */
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel &=
- ~(0x80000000 >> ISA_BRIDGE_INT);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel, in_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel & ~(0x80000000 >> ISA_BRIDGE_INT)));
if (setup_irq(ISA_BRIDGE_INT, &mbx_i8259_irqaction))
enable_irq(ISA_BRIDGE_INT);
diff --git a/arch/ppc/syslib/m8xx_wdt.c b/arch/ppc/syslib/m8xx_wdt.c
--- a/arch/ppc/syslib/m8xx_wdt.c
+++ b/arch/ppc/syslib/m8xx_wdt.c
@@ -29,8 +29,8 @@ void m8xx_wdt_reset(void)
{
volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
- imap->im_siu_conf.sc_swsr = 0x556c; /* write magic1 */
- imap->im_siu_conf.sc_swsr = 0xaa39; /* write magic2 */
+ out_be16(imap->im_siu_conf.sc_swsr, 0x556c); /* write magic1 */
+ out_be16(imap->im_siu_conf.sc_swsr, 0xaa39); /* write magic2 */
}
static irqreturn_t m8xx_wdt_interrupt(int irq, void *dev, struct pt_regs *regs)
@@ -39,7 +39,7 @@ static irqreturn_t m8xx_wdt_interrupt(in
m8xx_wdt_reset();
- imap->im_sit.sit_piscr |= PISCR_PS; /* clear irq */
+ out_be16(imap->im_sit.sit_piscr, in_be16(imap->im_sit.sit_piscr | PISCR_PS)); /* clear irq */
return IRQ_HANDLED;
}
@@ -51,7 +51,7 @@ void __init m8xx_wdt_handler_install(bd_
u32 sypcr;
u32 pitrtclk;
- sypcr = imap->im_siu_conf.sc_sypcr;
+ sypcr = in_be32(imap->im_siu_conf.sc_sypcr);
if (!(sypcr & 0x04)) {
printk(KERN_NOTICE "m8xx_wdt: wdt disabled (SYPCR: 0x%08X)\n",
@@ -87,9 +87,9 @@ void __init m8xx_wdt_handler_install(bd_
else
pitc = pitrtclk * wdt_timeout / binfo->bi_intfreq / 2;
- imap->im_sit.sit_pitc = pitc << 16;
- imap->im_sit.sit_piscr =
- (mk_int_int_mask(PIT_INTERRUPT) << 8) | PISCR_PIE | PISCR_PTE;
+ out_be32(imap->im_sit.sit_pitc, pitc << 16);
+
+ out_be16(imap->im_sit.sit_piscr, (mk_int_int_mask(PIT_INTERRUPT) << 8) | PISCR_PIE | PISCR_PTE);
if (setup_irq(PIT_INTERRUPT, &m8xx_wdt_irqaction))
panic("m8xx_wdt: error setting up the watchdog irq!");
diff --git a/arch/ppc/syslib/ppc8xx_pic.c b/arch/ppc/syslib/ppc8xx_pic.c
--- a/arch/ppc/syslib/ppc8xx_pic.c
+++ b/arch/ppc/syslib/ppc8xx_pic.c
@@ -6,6 +6,7 @@
#include <linux/signal.h>
#include <linux/interrupt.h>
#include <asm/irq.h>
+#include <asm/io.h>
#include <asm/8xx_immap.h>
#include <asm/mpc8xx.h>
#include "ppc8xx_pic.h"
@@ -29,8 +30,7 @@ static void m8xx_mask_irq(unsigned int i
word = irq_nr >> 5;
ppc_cached_irq_mask[word] &= ~(1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
static void m8xx_unmask_irq(unsigned int irq_nr)
@@ -41,8 +41,7 @@ static void m8xx_unmask_irq(unsigned int
word = irq_nr >> 5;
ppc_cached_irq_mask[word] |= (1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
static void m8xx_end_irq(unsigned int irq_nr)
@@ -55,8 +54,7 @@ static void m8xx_end_irq(unsigned int ir
word = irq_nr >> 5;
ppc_cached_irq_mask[word] |= (1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
}
@@ -69,9 +67,8 @@ static void m8xx_mask_and_ack(unsigned i
word = irq_nr >> 5;
ppc_cached_irq_mask[word] &= ~(1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sipend = 1 << (31-bit);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sipend, 1 << (31-bit));
}
struct hw_interrupt_type ppc8xx_pic = {
@@ -93,7 +90,7 @@ m8xx_get_irq(struct pt_regs *regs)
/* For MPC8xx, read the SIVEC register and shift the bits down
* to get the irq number.
*/
- irq = ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sivec >> 26;
+ irq = in_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sivec) >> 26;
/*
* When we read the sivec without an interrupt to process, we will
^ permalink raw reply
* Interrupt mapping for MPC8541
From: Bizhan Gholikhamseh (bgholikh) @ 2005-09-13 18:35 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
Hi ALL,
We are developing a custom board mother board based on
MPC8541 processor trying to run with Linux 2.6.11. The custom board has
hardwire the
interrupt lines for PCI peripherals with specific interrupt number for
each peripheral.
The MPC8541 has on Ethernet chip which during boot process the Linux
kernel assign
interrupt number 96 to it. Unfortunately one of our PCI peripheral that
is hardwire need that
interrupt number and this causes conflict.
Is there anyway we can avoid reserving this interrupt number so kernel
does not assign it unless it is asked specifically?
Thanks,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1982 bytes --]
^ permalink raw reply
* Re: __switch_to test-and-branch ALTIVEC specific?
From: Kumar Gala @ 2005-09-13 19:05 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-dev, linux-ppc-embedded
In-Reply-To: <20050913175028.GB14889@dmt.cnet>
This probably has to due with what happens on a G4 system with a
kernel not build with Altivec.. However, I dont remember exactly what
behavior is desired.
- kumar
On Sep 13, 2005, at 12:50 PM, Marcelo Tosatti wrote:
> Hi,
>
> This test&branch looks AltiVec specific, any reason for not #ifdef'ing
> it
> out?
>
> --- arch/ppc/kernel/process.c.orig 2005-09-13 14:43:13.000000000
> -0300
> +++ arch/ppc/kernel/process.c 2005-09-13 14:43:51.000000000 -0300
> @@ -287,11 +287,13 @@ struct task_struct *__switch_to(struct t
> #endif /* CONFIG_SPE */
> #endif /* CONFIG_SMP */
>
> +#ifdef CONFIG_ALTIVEC
> /* Avoid the trap. On smp this this never happens since
> * we don't set last_task_used_altivec -- Cort
> */
> if (new->thread.regs && last_task_used_altivec == new)
> new->thread.regs->msr |= MSR_VEC;
> +#endif
> #ifdef CONFIG_SPE
> /* Avoid the trap. On smp this this never happens since
> * we don't set last_task_used_spe
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Marvell MV6436xx ethernet driver patch
From: Dale Farnsworth @ 2005-09-13 20:01 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20050913103539.GA17855@lst.de>
On Tue, Sep 13, 2005 at 10:35:39AM +0000, Christoph Hellwig wrote:
> anywya, I think the patch discussion is rather offtopic here. Network
> driver patches are discussed and reviewed at netdev@oss.sgi.com
The current address is netdev@vger.kernel.org
I responded privately to Nicolas' message (before I realized it was posted
here). Still, I think it worth mentioning that a workaround for the
mv643xx_eth TCP/UDP hw checksum issue is already in 2.6.14-rc1.
-Dale
^ permalink raw reply
* Re: __switch_to test-and-branch ALTIVEC specific?
From: Marcelo Tosatti @ 2005-09-13 20:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, cort, linux-ppc-embedded
In-Reply-To: <A6CA30D6-DDC3-4AEF-8CA2-58CFA261F44B@freescale.com>
On Tue, Sep 13, 2005 at 02:05:57PM -0500, Kumar Gala wrote:
> This probably has to due with what happens on a G4 system with a
> kernel not build with Altivec.. However, I dont remember exactly what
> behavior is desired.
What would be the appropriate set of definitions to use, then ?
#if defined (CONFIG_ALTIVEC || CONFIG_6xx) ?
^ permalink raw reply
* PATCH powerpc: Merge asm-ppc*/hardirq.h
From: Jon Loeliger @ 2005-09-13 20:38 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, linuxppc64-dev
Here is a patch to merge asm-ppc*/hardirq.h.
Does anyone know of a problem in ppc64 land that
will be caused by having added the jiffy_stamp
field into this cacheline-aligned structure?
Also, of note here, I dodged the hard question
of what to do with SMP and preemption and stuff.
Lots more work will have to be resolved to really
answer those questions. Let's start here for now...
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
diff --git a/include/asm-powerpc/hardirq.h b/include/asm-powerpc/hardirq.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/hardirq.h
@@ -0,0 +1,36 @@
+#ifndef _ASM_POWERPC_HARDIRQ_H
+#define _ASM_POWERPC_HARDIRQ_H
+#ifdef __KERNEL__
+
+#include <linux/config.h>
+#include <linux/cache.h>
+
+#ifdef __powerpc64__
+#include <linux/preempt.h>
+#else
+#include <linux/smp_lock.h>
+#include <asm/irq.h>
+#endif
+
+/* The __last_jiffy_stamp field is needed to ensure that no decrementer
+ * interrupt is lost on SMP machines. Since on most CPUs it is in the same
+ * cache line as local_irq_count, it is cheap to access and is also used on UP
+ * for uniformity.
+ */
+typedef struct {
+ unsigned int __softirq_pending; /* set_bit is used on this */
+ unsigned int __last_jiffy_stamp;
+} ____cacheline_aligned irq_cpustat_t;
+
+#include <linux/irq_cpustat.h> /* Standard mappings for irq_cpustat_t above */
+
+#define last_jiffy_stamp(cpu) __IRQ_STAT((cpu), __last_jiffy_stamp)
+
+static inline void ack_bad_irq(int irq)
+{
+ printk(KERN_CRIT "illegal vector %d received!\n", irq);
+ BUG();
+}
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_HARDIRQ_H */
diff --git a/include/asm-ppc/hardirq.h b/include/asm-ppc/hardirq.h
deleted file mode 100644
--- a/include/asm-ppc/hardirq.h
+++ /dev/null
@@ -1,31 +0,0 @@
-#ifdef __KERNEL__
-#ifndef __ASM_HARDIRQ_H
-#define __ASM_HARDIRQ_H
-
-#include <linux/config.h>
-#include <linux/cache.h>
-#include <linux/smp_lock.h>
-#include <asm/irq.h>
-
-/* The __last_jiffy_stamp field is needed to ensure that no decrementer
- * interrupt is lost on SMP machines. Since on most CPUs it is in the same
- * cache line as local_irq_count, it is cheap to access and is also used on UP
- * for uniformity.
- */
-typedef struct {
- unsigned long __softirq_pending; /* set_bit is used on this */
- unsigned int __last_jiffy_stamp;
-} ____cacheline_aligned irq_cpustat_t;
-
-#include <linux/irq_cpustat.h> /* Standard mappings for irq_cpustat_t above */
-
-#define last_jiffy_stamp(cpu) __IRQ_STAT((cpu), __last_jiffy_stamp)
-
-static inline void ack_bad_irq(int irq)
-{
- printk(KERN_CRIT "illegal vector %d received!\n", irq);
- BUG();
-}
-
-#endif /* __ASM_HARDIRQ_H */
-#endif /* __KERNEL__ */
diff --git a/include/asm-ppc64/hardirq.h b/include/asm-ppc64/hardirq.h
deleted file mode 100644
--- a/include/asm-ppc64/hardirq.h
+++ /dev/null
@@ -1,27 +0,0 @@
-#ifndef __ASM_HARDIRQ_H
-#define __ASM_HARDIRQ_H
-
-/*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <linux/config.h>
-#include <linux/cache.h>
-#include <linux/preempt.h>
-
-typedef struct {
- unsigned int __softirq_pending;
-} ____cacheline_aligned irq_cpustat_t;
-
-#include <linux/irq_cpustat.h> /* Standard mappings for irq_cpustat_t above */
-
-static inline void ack_bad_irq(int irq)
-{
- printk(KERN_CRIT "illegal vector %d received!\n", irq);
- BUG();
-}
-
-#endif /* __ASM_HARDIRQ_H */
^ permalink raw reply
* PATCH powerpc: Merge asm-ppc*/sections.h
From: Jon Loeliger @ 2005-09-13 20:43 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, linuxppc64-dev
Here is a patch to merge asm-ppc*/sections.h.
If anyone knows if we can do better here,
please feel free to abuse, er, let me know!
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
diff --git a/include/asm-powerpc/sections.h b/include/asm-powerpc/sections.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/sections.h
@@ -0,0 +1,62 @@
+#ifndef _ASM_POWERPC_SECTIONS_H
+#define _ASM_POWERPC_SECTIONS_H
+
+#ifdef __KERNEL__
+
+#include <asm-generic/sections.h>
+
+#ifdef __powerpc64__
+
+#define __pmac
+#define __pmacdata
+
+#define __prep
+#define __prepdata
+
+#define __chrp
+#define __chrpdata
+
+#define __openfirmware
+#define __openfirmwaredata
+
+extern char _end[];
+
+static inline int in_kernel_text(unsigned long addr)
+{
+ if (addr >= (unsigned long)_stext && addr < (unsigned long)__init_end)
+ return 1;
+
+ return 0;
+}
+
+#else /* __powerpc64__ */
+
+#define __pmac __attribute__ ((__section__ (".pmac.text")))
+#define __pmacdata __attribute__ ((__section__ (".pmac.data")))
+#define __pmacfunc(__argpmac) \
+ __argpmac __pmac; \
+ __argpmac
+
+#define __prep __attribute__ ((__section__ (".prep.text")))
+#define __prepdata __attribute__ ((__section__ (".prep.data")))
+#define __prepfunc(__argprep) \
+ __argprep __prep; \
+ __argprep
+
+#define __chrp __attribute__ ((__section__ (".chrp.text")))
+#define __chrpdata __attribute__ ((__section__ (".chrp.data")))
+#define __chrpfunc(__argchrp) \
+ __argchrp __chrp; \
+ __argchrp
+
+/* this is actually just common chrp/pmac code, not OF code -- Cort */
+#define __openfirmware __attribute__ ((__section__ (".openfirmware.text")))
+#define __openfirmwaredata __attribute__ ((__section__ (".openfirmware.data")))
+#define __openfirmwarefunc(__argopenfirmware) \
+ __argopenfirmware __openfirmware; \
+ __argopenfirmware
+
+#endif /* __powerpc64__ */
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_SECTIONS_H */
diff --git a/include/asm-ppc/sections.h b/include/asm-ppc/sections.h
deleted file mode 100644
--- a/include/asm-ppc/sections.h
+++ /dev/null
@@ -1,33 +0,0 @@
-#ifdef __KERNEL__
-#ifndef _PPC_SECTIONS_H
-#define _PPC_SECTIONS_H
-
-#include <asm-generic/sections.h>
-
-#define __pmac __attribute__ ((__section__ (".pmac.text")))
-#define __pmacdata __attribute__ ((__section__ (".pmac.data")))
-#define __pmacfunc(__argpmac) \
- __argpmac __pmac; \
- __argpmac
-
-#define __prep __attribute__ ((__section__ (".prep.text")))
-#define __prepdata __attribute__ ((__section__ (".prep.data")))
-#define __prepfunc(__argprep) \
- __argprep __prep; \
- __argprep
-
-#define __chrp __attribute__ ((__section__ (".chrp.text")))
-#define __chrpdata __attribute__ ((__section__ (".chrp.data")))
-#define __chrpfunc(__argchrp) \
- __argchrp __chrp; \
- __argchrp
-
-/* this is actually just common chrp/pmac code, not OF code -- Cort */
-#define __openfirmware __attribute__ ((__section__ (".openfirmware.text")))
-#define __openfirmwaredata __attribute__ ((__section__ (".openfirmware.data")))
-#define __openfirmwarefunc(__argopenfirmware) \
- __argopenfirmware __openfirmware; \
- __argopenfirmware
-
-#endif /* _PPC_SECTIONS_H */
-#endif /* __KERNEL__ */
diff --git a/include/asm-ppc64/sections.h b/include/asm-ppc64/sections.h
deleted file mode 100644
--- a/include/asm-ppc64/sections.h
+++ /dev/null
@@ -1,29 +0,0 @@
-#ifndef _PPC64_SECTIONS_H
-#define _PPC64_SECTIONS_H
-
-extern char _end[];
-
-#include <asm-generic/sections.h>
-
-#define __pmac
-#define __pmacdata
-
-#define __prep
-#define __prepdata
-
-#define __chrp
-#define __chrpdata
-
-#define __openfirmware
-#define __openfirmwaredata
-
-
-static inline int in_kernel_text(unsigned long addr)
-{
- if (addr >= (unsigned long)_stext && addr < (unsigned long)__init_end)
- return 1;
-
- return 0;
-}
-
-#endif
^ permalink raw reply
* Re: __switch_to test-and-branch ALTIVEC specific?
From: Kumar Gala @ 2005-09-13 21:43 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-dev, cort, linux-ppc-embedded
In-Reply-To: <20050913203555.GB18639@dmt.cnet>
On Sep 13, 2005, at 3:35 PM, Marcelo Tosatti wrote:
> On Tue, Sep 13, 2005 at 02:05:57PM -0500, Kumar Gala wrote:
>
>> This probably has to due with what happens on a G4 system with a
>> kernel not build with Altivec.. However, I dont remember exactly what
>>
>
>
>> behavior is desired.
>>
>
> What would be the appropriate set of definitions to use, then ?
>
> #if defined (CONFIG_ALTIVEC || CONFIG_6xx) ?
That's probably better. Hopefully Ben will have some reason if what
you suggest is not sufficient.
- k
^ permalink raw reply
* -dev and -embedded cross-posting
From: Eugene Surovegin @ 2005-09-13 22:23 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050913175028.GB14889@dmt.cnet>
Guys,
let's not cross-post -dev posts here. In general, -embedded isn't
a totally separate list, it just covers embedded specific stuff, which
is not interesting to several loud -dev readers :). Things which
aren't embedded specific should go -dev.
I think, everybody *interested* in general PPC32 development issues
here, are also subscribed to -dev list.
Thanks.
--
Eugene
^ permalink raw reply
* Re: PATCH powerpc: Merge asm-ppc*/sections.h
From: Arnd Bergmann @ 2005-09-14 2:35 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1126644202.11056.59.camel@cashmere.sps.mot.com>
On Dinsdag 13 September 2005 22:43, Jon Loeliger wrote:
> Here is a patch to merge asm-ppc*/sections.h.
>
> If anyone knows if we can do better here,
> please feel free to abuse, er, let me know!
Ok, I don't like this patch. IMHO for the architecture merge, we should
have a common implementation of this, either always using per-platform
sections or never using them, meaning that we get rid of this file.
At the very least, the __*func() macros should go away, they are completely
bogus.
Using the sections in arch/powerpc has the obvious advantage that it
reduces the size of the running kernel, but also has a certain amount
of bug-potential or at least makes the code slightly more ugly.
It is also easier to remove the feature in ppc than adding it in ppc64.
The users of the ppc64 function in_kernel_text() can probably be converted
to the generic is_kernel_text() function.
Arnd <><
^ permalink raw reply
* How to modify MTD driver for MX29LV320ABTC-90?
From: 徐小威的EMAIL @ 2005-09-14 6:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi All:
I used 2.4.25 linux at my custom MPC852T.My hardware has 2 *
MX29LV320ABTC, working at 16bit mode.Now i want to used MTD to partion
my flash and JFFS2.I want to know how
to modify MTD for MX29LV320ABTC.
init_tqm_mtd: chip probing count 0
init_tqm_mtd: chip probing count 1
TQM8xxL: No support flash chips found!
PS:My first flash address start at 0x40000000, second is 0x40400000
Best Regards,
Rober Hsu
^ permalink raw reply
* 1161 host
From: 汪 秀平 @ 2005-09-14 7:27 UTC (permalink / raw)
To: linuxppc-embedded
hello
1161 connect question:
don't connect usboperational state
bases: ISP1161xProgramming_Guide.pdf
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ 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