* Re: Problem running Linux 2.6.11 on MPC8272ADS
From: Kumar Gala @ 2005-03-28 16:21 UTC (permalink / raw)
To: Walter L. Wimer III; +Cc: linuxppc-embedded
In-Reply-To: <1112026020.25896.8.camel@excalibur.timesys.com>
A patch to make this work properly would be appreciated.
- kumar
On Mar 28, 2005, at 10:06 AM, Walter L. Wimer III wrote:
>
>
> Hi Mike,
>
> I had the same "hang" experience.=A0 The file =
arch/ppc/platforms/pq2ads.c
> contains the following function:
>
> =A0 void __init
> =A0 m82xx_board_setup(void)
> =A0 {
> =A0 =A0=A0=A0=A0=A0 /* Enable the 2nd UART port */
> =A0 =A0=A0=A0=A0=A0 *(volatile uint *)(BCSR_ADDR + 4) &=3D =
~BCSR1_RS232_EN2;
> =A0 }
>
>
>
> I had to ifdef-out the assignment statement above.=A0 It appears that =
the
> definition for BCSR_ADDR in the kernel code differs from what U-Boot=20=
> is
> using, and that area of memory isn't properly mapped into the kernel
> address space this early in the boot sequence.=A0 As a result, I was
> getting an Oops() before the console was even enabled (I could see =
the
> Oops message by examining the kernel's printk log buffer using a
> BDI-2000 hardware debugger).
>
>
>
>
> Good luck,
>
> Walt Wimer
> TimeSys Corporation
>
>
>
>
>
> On Sun, 2005-03-27 at 11:31 +0200, Mike Rapoport wrote:
> > Hi,
> > I'm trying to bring up the Linux 2.6.11 on MPC8272ADS and it seem =
to
> > hang up at the very beginning.
> > I use ads8272_defconfig and then enable console on SCC:
> >
> > CONFIG_SERIAL_CPM=3Dy
> > CONFIG_SERIAL_CPM_CONSOLE=3Dy
> > CONFIG_SERIAL_CPM_SCC1=3Dy
> >
> >
> > when I boot the kernel from the u-boot the system hangs up right=20
> after
> > the kernel decompression.
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Problem running Linux 2.6.11 on MPC8272ADS
From: Walter L. Wimer III @ 2005-03-28 16:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <4a399aeb5127923823feb2ced5eb0e1d@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]
I'll submit one once I get everything else working on this board that I
need.... :-)
Walt
On Mon, 2005-03-28 at 10:21 -0600, Kumar Gala wrote:
> A patch to make this work properly would be appreciated.
>
> - kumar
>
> On Mar 28, 2005, at 10:06 AM, Walter L. Wimer III wrote:
>
> >
> >
> > Hi Mike,
> >
> > I had the same "hang" experience. The file arch/ppc/platforms/pq2ads.c
> > contains the following function:
> >
> > void __init
> > m82xx_board_setup(void)
> > {
> > /* Enable the 2nd UART port */
> > *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;
> > }
> >
> >
> >
> > I had to ifdef-out the assignment statement above. It appears that the
> > definition for BCSR_ADDR in the kernel code differs from what U-Boot
> > is
> > using, and that area of memory isn't properly mapped into the kernel
> > address space this early in the boot sequence. As a result, I was
> > getting an Oops() before the console was even enabled (I could see the
> > Oops message by examining the kernel's printk log buffer using a
> > BDI-2000 hardware debugger).
> >
> >
> >
> >
> > Good luck,
> >
> > Walt Wimer
> > TimeSys Corporation
> >
> >
> >
> >
> >
> > On Sun, 2005-03-27 at 11:31 +0200, Mike Rapoport wrote:
> > > Hi,
> > > I'm trying to bring up the Linux 2.6.11 on MPC8272ADS and it seem to
> > > hang up at the very beginning.
> > > I use ads8272_defconfig and then enable console on SCC:
> > >
> > > CONFIG_SERIAL_CPM=y
> > > CONFIG_SERIAL_CPM_CONSOLE=y
> > > CONFIG_SERIAL_CPM_SCC1=y
> > >
> > >
> > > when I boot the kernel from the u-boot the system hangs up right
> > after
> > > the kernel decompression.
> > >
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 4225 bytes --]
^ permalink raw reply
* Re: Question regarding Interrupt "delivery" to user mode process
From: David Bruce @ 2005-03-28 16:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050325221320.004DC67AB2@ozlabs.org>
The below link contain code snippets that process SONET events via an
interrupt. Basically an user space application waits on an ioctl call
for events that are queued. These events are queued via a kernel thread
that waits on a wait_event_interruptible call. When an interupt happens
the thread processes the events, timestamps them and puts a message on a
queue.
There is other code that is left out the starts the thread. If you are
interested...ask.
http://www.geocities.com/dbruce_01721/event.c
^ permalink raw reply
* ASM formatting rules?
From: Kumar Gala @ 2005-03-28 16:44 UTC (permalink / raw)
To: Paul Mackerras, Tom Rini, Matt Porter, Benjamin Herrenschmidt
Cc: linuxppc-dev list, ML linuxppc-embedded
Guys,
While this is not overly important to me, I was wondering if we had any
rules related to formatting of assembly files. We seem to have code
formatted with and without spaces in the args.
I'm assuming something like this (w/o spaces):
<TAB>insn<TAB>argD,arg1,arg2
is what we want? Just trying to get a rule documented going forward.
- kumar
^ permalink raw reply
* Re: ASM formatting rules?
From: Tom Rini @ 2005-03-28 16:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras, ML linuxppc-embedded
In-Reply-To: <ffec644f8c4f3bc32922882631c0da3e@freescale.com>
On Mon, Mar 28, 2005 at 10:44:17AM -0600, Kumar Gala wrote:
> Guys,
>
> While this is not overly important to me, I was wondering if we had any
> rules related to formatting of assembly files. We seem to have code
> formatted with and without spaces in the args.
>
> I'm assuming something like this (w/o spaces):
>
> <TAB>insn<TAB>argD,arg1,arg2
>
> is what we want? Just trying to get a rule documented going forward.
My preference is for spaces after each , just because it makes it
visually clearer (and I don't always have instant mental insn->#args
mental mapping :)).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: ASM formatting rules?
From: Dan Malek @ 2005-03-28 17:11 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev list, Paul Mackerras, ML linuxppc-embedded
In-Reply-To: <20050328165610.GG25923@smtp.west.cox.net>
On Mar 28, 2005, at 11:56 AM, Tom Rini wrote:
> My preference is for spaces after each , just because it makes it
Me, too.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 3/3] PPC440EP IBM EMAC support
From: Wade Farnsworth @ 2005-03-28 17:52 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050315133710.B5861@cox.net>
On Tue, 2005-03-15 at 13:37, Matt Porter wrote:
> On Tue, Mar 15, 2005 at 11:22:16AM -0800, Eugene Surovegin wrote:
> > On Tue, Mar 15, 2005 at 11:58:54AM -0700, Wade Farnsworth wrote:
> > > This patch adds support to the IBM EMAC ethernet driver for the 440EP.
> > >
> > > Regards,
> > > Wade Farnsworth
> > >
> > > Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
> > >
> >
> > > --- linux-2.6.11-bk7/drivers/net/ibm_emac/ibm_emac_phy.c 2005-03-02 00:38:13.000000000 -0700
> > > +++ linux-2.6.11-bk7-440ep/drivers/net/ibm_emac/ibm_emac_phy.c 2005-03-11 16:32:01.000000000 -0700
> > > @@ -27,6 +27,12 @@
> > >
> > > #include "ibm_emac_phy.h"
> > >
> > > +#ifdef CONFIG_BAMBOO
> > > +#define BAMBOO_REV0 (mfspr(PVR) == PVR_440EP_RA)
> > > +#else
> > > +#define BAMBOO_REV0 0
> > > +#endif
> > > +
> >
> > I really don't like it. Chip revision doesn't imply which board
> > this code is running on. Please, think of some other way to do this or
> > drop this completely.
>
> Wade and I talked about this one before and there is no direct way
> to detect the board revision on this platform. Given that, I
> think that if the PVR of the 440EP in a Bamboo board does imply
> the board revision, then this is appropriate.
I emailed AMCC support about the 440EP eval board revision situation and
(finally) got a reply.
It seems there are no plans to replace the Rev 0 boards with Rev 1
boards. It is, therefore, conceivable that some users will have Rev 0
boards, and will need the workaround in the patch. Others will have Rev
1 boards, which work fine with the current version of the driver.
So it looks like there will have to be some sort of way to determine
which board the kernel is running on. According to AMCC, all Rev 0's
have the 440EP Rev A processor and all Rev 1's have the 440EP Rev B
processor. AMCC also says that the best way for software to determine
to determine which board rev it is running on is to either use the PVR
or the JTAG ID. I agree this is not an ideal solution, but it seems to
be the best one.
I am, however, open to suggestions, if anyone knows of a better
solution.
Thanks,
-Wade Farnsworth
^ permalink raw reply
* Re: ASM formatting rules?
From: Matt Porter @ 2005-03-28 17:22 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev list, Paul Mackerras, ML linuxppc-embedded
In-Reply-To: <20050328165610.GG25923@smtp.west.cox.net>
On Mon, Mar 28, 2005 at 09:56:11AM -0700, Tom Rini wrote:
> On Mon, Mar 28, 2005 at 10:44:17AM -0600, Kumar Gala wrote:
> > Guys,
> >
> > While this is not overly important to me, I was wondering if we had any
> > rules related to formatting of assembly files. We seem to have code
> > formatted with and without spaces in the args.
> >
> > I'm assuming something like this (w/o spaces):
> >
> > <TAB>insn<TAB>argD,arg1,arg2
> >
> > is what we want? Just trying to get a rule documented going forward.
>
> My preference is for spaces after each , just because it makes it
> visually clearer (and I don't always have instant mental insn->#args
> mental mapping :)).
As long as there is <TAG>insn<TAB>, I don't have strong feelings
about the arg spacing. I feel that spaces between args really
don't enhance readability (why I have none between args in
head_44x.S) but I can live with them.
I think this is a good idea to get some consistency throughout
ppc32 asm.
-Matt
^ permalink raw reply
* Re: ASM formatting rules?
From: Paul Mackerras @ 2005-03-28 21:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: Tom Rini, linuxppc-dev list, ML linuxppc-embedded
In-Reply-To: <ffec644f8c4f3bc32922882631c0da3e@freescale.com>
Kumar Gala writes:
> I'm assuming something like this (w/o spaces):
>
> <TAB>insn<TAB>argD,arg1,arg2
>
> is what we want? Just trying to get a rule documented going forward.
Yep, that's the style we use.
Paul.
^ permalink raw reply
* Re: ASM formatting rules?
From: Benjamin Herrenschmidt @ 2005-03-28 22:21 UTC (permalink / raw)
To: Kumar Gala
Cc: Tom Rini, linuxppc-dev list, Paul Mackerras, ML linuxppc-embedded
In-Reply-To: <ffec644f8c4f3bc32922882631c0da3e@freescale.com>
On Mon, 2005-03-28 at 10:44 -0600, Kumar Gala wrote:
> Guys,
>
> While this is not overly important to me, I was wondering if we had any
> rules related to formatting of assembly files. We seem to have code
> formatted with and without spaces in the args.
>
> I'm assuming something like this (w/o spaces):
>
> <TAB>insn<TAB>argD,arg1,arg2
>
> is what we want? Just trying to get a rule documented going forward.
I used to have argD, arg1, arg2 but since everything else was "compact",
I now tend to adapt to everything else ;)
Ben.
^ permalink raw reply
* [PATCH] ppc32: cleanup of Book-E exception handling
From: Kumar Gala @ 2005-03-28 23:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Andrew,
Cleaned up the Book-E exception handling code to remove saving/restoring
registers that were not needed. Moved the register save/restore area onto
the exception stacks instead of dedicated offsets. Additionally, this
allows for proper SMP handling of the additional exception levels.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
--- a/arch/ppc/kernel/entry.S 2005-03-28 14:24:24 -06:00
+++ b/arch/ppc/kernel/entry.S 2005-03-28 14:24:24 -06:00
@@ -45,40 +45,37 @@
#endif
#ifdef CONFIG_BOOKE
-#define COR r8 /* Critical Offset Register (COR) */
-#define BOOKE_LOAD_COR lis COR,crit_save@ha
-#define BOOKE_REST_COR mfspr COR,SPRN_SPRG2
-#define BOOKE_SAVE_COR mtspr SPRN_SPRG2,COR
-#else
-#define COR 0
-#define BOOKE_LOAD_COR
-#define BOOKE_REST_COR
-#define BOOKE_SAVE_COR
-#endif
-
-#ifdef CONFIG_BOOKE
+#include "head_booke.h"
.globl mcheck_transfer_to_handler
mcheck_transfer_to_handler:
- mtspr SPRN_SPRG6W,r8
- lis r8,mcheck_save@ha
- lwz r0,mcheck_r10@l(r8)
+ mtspr MCHECK_SPRG,r8
+ BOOKE_LOAD_MCHECK_STACK
+ lwz r0,GPR10-INT_FRAME_SIZE(r8)
stw r0,GPR10(r11)
- lwz r0,mcheck_r11@l(r8)
+ lwz r0,GPR11-INT_FRAME_SIZE(r8)
stw r0,GPR11(r11)
- mfspr r8,SPRN_SPRG6R
+ mfspr r8,MCHECK_SPRG
b transfer_to_handler_full
+
+ .globl crit_transfer_to_handler
+crit_transfer_to_handler:
+ mtspr CRIT_SPRG,r8
+ BOOKE_LOAD_CRIT_STACK
+ lwz r0,GPR10-INT_FRAME_SIZE(r8)
+ stw r0,GPR10(r11)
+ lwz r0,GPR11-INT_FRAME_SIZE(r8)
+ stw r0,GPR11(r11)
+ mfspr r8,CRIT_SPRG
+ /* fall through */
#endif
-#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+#ifdef CONFIG_40x
.globl crit_transfer_to_handler
crit_transfer_to_handler:
- BOOKE_SAVE_COR
- BOOKE_LOAD_COR
- lwz r0,crit_r10@l(COR)
+ lwz r0,crit_r10@l(0)
stw r0,GPR10(r11)
- lwz r0,crit_r11@l(COR)
+ lwz r0,crit_r11@l(0)
stw r0,GPR11(r11)
- BOOKE_REST_COR
/* fall through */
#endif
@@ -724,8 +721,6 @@
* We have to restore various SPRs that may have been in use at the
* time of the critical interrupt.
*
- * Note that SPRG6 is used for machine check on CONFIG_BOOKE parts and
- * thus not saved in the critical handler
*/
.globl ret_from_crit_exc
ret_from_crit_exc:
@@ -770,32 +765,9 @@
mtspr SPRN_CSRR1,r12
lwz r9,GPR9(r1)
lwz r12,GPR12(r1)
- BOOKE_SAVE_COR
- BOOKE_LOAD_COR
- lwz r10,crit_sprg0@l(COR)
- mtspr SPRN_SPRG0,r10
- lwz r10,crit_sprg1@l(COR)
- mtspr SPRN_SPRG1,r10
- lwz r10,crit_sprg4@l(COR)
- mtspr SPRN_SPRG4,r10
- lwz r10,crit_sprg5@l(COR)
- mtspr SPRN_SPRG5,r10
-#ifdef CONFIG_40x
- lwz r10,crit_sprg6@l(COR)
- mtspr SPRN_SPRG6,r10
-#endif
- lwz r10,crit_sprg7@l(COR)
- mtspr SPRN_SPRG7,r10
- lwz r10,crit_srr0@l(COR)
- mtspr SPRN_SRR0,r10
- lwz r10,crit_srr1@l(COR)
- mtspr SPRN_SRR1,r10
- lwz r10,crit_pid@l(COR)
- mtspr SPRN_PID,r10
lwz r10,GPR10(r1)
lwz r11,GPR11(r1)
lwz r1,GPR1(r1)
- BOOKE_REST_COR
PPC405_ERR77_SYNC
rfci
b . /* prevent prefetch past rfci */
@@ -839,32 +811,9 @@
mtspr SPRN_MCSRR1,r12
lwz r9,GPR9(r1)
lwz r12,GPR12(r1)
- mtspr SPRN_SPRG6W,r8
- lis r8,mcheck_save@ha
- lwz r10,mcheck_sprg0@l(r8)
- mtspr SPRN_SPRG0,r10
- lwz r10,mcheck_sprg1@l(r8)
- mtspr SPRN_SPRG1,r10
- lwz r10,mcheck_sprg4@l(r8)
- mtspr SPRN_SPRG4,r10
- lwz r10,mcheck_sprg5@l(r8)
- mtspr SPRN_SPRG5,r10
- lwz r10,mcheck_sprg7@l(r8)
- mtspr SPRN_SPRG7,r10
- lwz r10,mcheck_srr0@l(r8)
- mtspr SPRN_SRR0,r10
- lwz r10,mcheck_srr1@l(r8)
- mtspr SPRN_SRR1,r10
- lwz r10,mcheck_csrr0@l(r8)
- mtspr SPRN_CSRR0,r10
- lwz r10,mcheck_csrr1@l(r8)
- mtspr SPRN_CSRR1,r10
- lwz r10,mcheck_pid@l(r8)
- mtspr SPRN_PID,r10
lwz r10,GPR10(r1)
lwz r11,GPR11(r1)
lwz r1,GPR1(r1)
- mfspr r8,SPRN_SPRG6R
RFMCI
#endif /* CONFIG_BOOKE */
diff -Nru a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S
--- a/arch/ppc/kernel/head_44x.S 2005-03-28 14:24:24 -06:00
+++ b/arch/ppc/kernel/head_44x.S 2005-03-28 14:24:24 -06:00
@@ -728,78 +728,13 @@
_GLOBAL(swapper_pg_dir)
.space 8192
+/* Reserved 4k for the critical exception stack & 4k for the machine
+ * check stack per CPU for kernel mode exceptions */
.section .bss
-/* Stack for handling critical exceptions from kernel mode */
-critical_stack_bottom:
- .space 4096
-critical_stack_top:
- .previous
-
-/* Stack for handling machine check exceptions from kernel mode */
-mcheck_stack_bottom:
- .space 4096
-mcheck_stack_top:
- .previous
-
-/*
- * This area is used for temporarily saving registers during the
- * critical and machine check exception prologs. It must always
- * follow the page aligned allocations, so it starts on a page
- * boundary, ensuring that all crit_save areas are in a single
- * page.
- */
-
-/* crit_save */
-_GLOBAL(crit_save)
- .space 4
-_GLOBAL(crit_r10)
- .space 4
-_GLOBAL(crit_r11)
- .space 4
-_GLOBAL(crit_sprg0)
- .space 4
-_GLOBAL(crit_sprg1)
- .space 4
-_GLOBAL(crit_sprg4)
- .space 4
-_GLOBAL(crit_sprg5)
- .space 4
-_GLOBAL(crit_sprg7)
- .space 4
-_GLOBAL(crit_pid)
- .space 4
-_GLOBAL(crit_srr0)
- .space 4
-_GLOBAL(crit_srr1)
- .space 4
-
-/* mcheck_save */
-_GLOBAL(mcheck_save)
- .space 4
-_GLOBAL(mcheck_r10)
- .space 4
-_GLOBAL(mcheck_r11)
- .space 4
-_GLOBAL(mcheck_sprg0)
- .space 4
-_GLOBAL(mcheck_sprg1)
- .space 4
-_GLOBAL(mcheck_sprg4)
- .space 4
-_GLOBAL(mcheck_sprg5)
- .space 4
-_GLOBAL(mcheck_sprg7)
- .space 4
-_GLOBAL(mcheck_pid)
- .space 4
-_GLOBAL(mcheck_srr0)
- .space 4
-_GLOBAL(mcheck_srr1)
- .space 4
-_GLOBAL(mcheck_csrr0)
- .space 4
-_GLOBAL(mcheck_csrr1)
- .space 4
+ .align 12
+exception_stack_bottom:
+ .space BOOKE_EXCEPTION_STACK_SIZE
+_GLOBAL(exception_stack_top)
/*
* This space gets a copy of optional info passed to us by the bootstrap
diff -Nru a/arch/ppc/kernel/head_4xx.S b/arch/ppc/kernel/head_4xx.S
--- a/arch/ppc/kernel/head_4xx.S 2005-03-28 14:24:24 -06:00
+++ b/arch/ppc/kernel/head_4xx.S 2005-03-28 14:24:24 -06:00
@@ -95,24 +95,6 @@
.space 4
_GLOBAL(crit_r11)
.space 4
-_GLOBAL(crit_sprg0)
- .space 4
-_GLOBAL(crit_sprg1)
- .space 4
-_GLOBAL(crit_sprg4)
- .space 4
-_GLOBAL(crit_sprg5)
- .space 4
-_GLOBAL(crit_sprg6)
- .space 4
-_GLOBAL(crit_sprg7)
- .space 4
-_GLOBAL(crit_pid)
- .space 4
-_GLOBAL(crit_srr0)
- .space 4
-_GLOBAL(crit_srr1)
- .space 4
/*
* Exception vector entry code. This code runs with address translation
@@ -165,24 +147,6 @@
#define CRITICAL_EXCEPTION_PROLOG \
stw r10,crit_r10@l(0); /* save two registers to work with */\
stw r11,crit_r11@l(0); \
- mfspr r10,SPRN_SPRG0; \
- stw r10,crit_sprg0@l(0); \
- mfspr r10,SPRN_SPRG1; \
- stw r10,crit_sprg1@l(0); \
- mfspr r10,SPRN_SPRG4; \
- stw r10,crit_sprg4@l(0); \
- mfspr r10,SPRN_SPRG5; \
- stw r10,crit_sprg5@l(0); \
- mfspr r10,SPRN_SPRG6; \
- stw r10,crit_sprg6@l(0); \
- mfspr r10,SPRN_SPRG7; \
- stw r10,crit_sprg7@l(0); \
- mfspr r10,SPRN_PID; \
- stw r10,crit_pid@l(0); \
- mfspr r10,SPRN_SRR0; \
- stw r10,crit_srr0@l(0); \
- mfspr r10,SPRN_SRR1; \
- stw r10,crit_srr1@l(0); \
mfcr r10; /* save CR in r10 for now */\
mfspr r11,SPRN_SRR3; /* check whether user or kernel */\
andi. r11,r11,MSR_PR; \
@@ -221,9 +185,6 @@
* r11 saved in crit_r11 and in stack frame,
* now phys stack/exception frame pointer
* r12 saved in stack frame, now saved SRR2
- * SPRG0,1,4,5,6,7 saved in crit_sprg0,1,4,5,6,7
- * PID saved in crit_pid
- * SRR0,1 saved in crit_srr0,1
* CR saved in stack frame, CR0.EQ = !SRR3.PR
* LR, DEAR, ESR in stack frame
* r1 saved in stack frame, now virt stack/excframe pointer
@@ -1030,10 +991,11 @@
/* Stack for handling critical exceptions from kernel mode */
.section .bss
-critical_stack_bottom:
+ .align 12
+exception_stack_bottom:
.space 4096
critical_stack_top:
- .previous
+_GLOBAL(exception_stack_top)
/* This space gets a copy of optional info passed to us by the bootstrap
* which is used to pass parameters into the kernel like root=/dev/sda1, etc.
diff -Nru a/arch/ppc/kernel/head_booke.h b/arch/ppc/kernel/head_booke.h
--- a/arch/ppc/kernel/head_booke.h 2005-03-28 14:24:24 -06:00
+++ b/arch/ppc/kernel/head_booke.h 2005-03-28 14:24:24 -06:00
@@ -22,7 +22,7 @@
lwz r1,THREAD_INFO-THREAD(r1); /* this thread's kernel stack */\
addi r1,r1,THREAD_SIZE; \
1: subi r1,r1,INT_FRAME_SIZE; /* Allocate an exception frame */\
- tophys(r11,r1); \
+ mr r11,r1; \
stw r10,_CCR(r11); /* save various registers */\
stw r12,GPR12(r11); \
stw r9,GPR9(r11); \
@@ -42,45 +42,71 @@
SAVE_4GPRS(3, r11); \
SAVE_2GPRS(7, r11)
+/* To handle the additional exception priority levels on 40x and Book-E
+ * processors we allocate a 4k stack per additional priority level. The various
+ * head_xxx.S files allocate space (exception_stack_top) for each priority's
+ * stack times the number of CPUs
+ *
+ * On 40x critical is the only additional level
+ * On 44x/e500 we have critical and machine check
+ *
+ * Additionally we reserve a SPRG for each priority level so we can free up a
+ * GPR to use as the base for indirect access to the exception stacks. This
+ * is necessary since the MMU is always on, for Book-E parts, and the stacks
+ * are offset from KERNELBASE.
+ *
+ */
+#define BOOKE_EXCEPTION_STACK_SIZE (8192)
+
+/* CRIT_SPRG only used in critical exception handling */
+#define CRIT_SPRG SPRN_SPRG2
+/* MCHECK_SPRG only used in critical exception handling */
+#define MCHECK_SPRG SPRN_SPRG6W
+
+#define MCHECK_STACK_TOP (exception_stack_top - 4096)
+#define CRIT_STACK_TOP (exception_stack_top)
+
+#ifdef CONFIG_SMP
+#define BOOKE_LOAD_CRIT_STACK \
+ mfspr r8,SPRN_PIR; \
+ mulli r8,r8,BOOKE_EXCEPTION_STACK_SIZE; \
+ neg r8,r8; \
+ addis r8,r8,CRIT_STACK_TOP@ha; \
+ addi r8,r8,CRIT_STACK_TOP@l
+#define BOOKE_LOAD_MCHECK_STACK \
+ mfspr r8,SPRN_PIR; \
+ mulli r8,r8,BOOKE_EXCEPTION_STACK_SIZE; \
+ neg r8,r8; \
+ addis r8,r8,MCHECK_STACK_TOP@ha; \
+ addi r8,r8,MCHECK_STACK_TOP@l
+#else
+#define BOOKE_LOAD_CRIT_STACK \
+ lis r8,CRIT_STACK_TOP@h; \
+ ori r8,r8,CRIT_STACK_TOP@l
+#define BOOKE_LOAD_MCHECK_STACK \
+ lis r8,MCHECK_STACK_TOP@h; \
+ ori r8,r8,MCHECK_STACK_TOP@l
+#endif
+
/*
* Exception prolog for critical exceptions. This is a little different
* from the normal exception prolog above since a critical exception
* can potentially occur at any point during normal exception processing.
* Thus we cannot use the same SPRG registers as the normal prolog above.
- * Instead we use a couple of words of memory at low physical addresses.
- * This is OK since we don't support SMP on these processors. For Book E
- * processors, we also have a reserved register (SPRG2) that is only used
- * in critical exceptions so we can free up a GPR to use as the base for
- * indirect access to the critical exception save area. This is necessary
- * since the MMU is always on and the save area is offset from KERNELBASE.
+ * Instead we use a portion of the critical exception stack at low physical
+ * addresses.
*/
+
#define CRITICAL_EXCEPTION_PROLOG \
- mtspr SPRN_SPRG2,r8; /* SPRG2 only used in criticals */ \
- lis r8,crit_save@ha; \
- stw r10,crit_r10@l(r8); \
- stw r11,crit_r11@l(r8); \
- mfspr r10,SPRN_SPRG0; \
- stw r10,crit_sprg0@l(r8); \
- mfspr r10,SPRN_SPRG1; \
- stw r10,crit_sprg1@l(r8); \
- mfspr r10,SPRN_SPRG4R; \
- stw r10,crit_sprg4@l(r8); \
- mfspr r10,SPRN_SPRG5R; \
- stw r10,crit_sprg5@l(r8); \
- mfspr r10,SPRN_SPRG7R; \
- stw r10,crit_sprg7@l(r8); \
- mfspr r10,SPRN_PID; \
- stw r10,crit_pid@l(r8); \
- mfspr r10,SPRN_SRR0; \
- stw r10,crit_srr0@l(r8); \
- mfspr r10,SPRN_SRR1; \
- stw r10,crit_srr1@l(r8); \
- mfspr r8,SPRN_SPRG2; /* SPRG2 only used in criticals */ \
+ mtspr CRIT_SPRG,r8; \
+ BOOKE_LOAD_CRIT_STACK; /* r8 points to the crit stack */ \
+ stw r10,GPR10-INT_FRAME_SIZE(r8); \
+ stw r11,GPR11-INT_FRAME_SIZE(r8); \
mfcr r10; /* save CR in r10 for now */\
mfspr r11,SPRN_CSRR1; /* check whether user or kernel */\
andi. r11,r11,MSR_PR; \
- lis r11,critical_stack_top@h; \
- ori r11,r11,critical_stack_top@l; \
+ mr r11,r8; \
+ mfspr r8,CRIT_SPRG; \
beq 1f; \
/* COMING FROM USER MODE */ \
mfspr r11,SPRN_SPRG3; /* if from user, start at top of */\
@@ -100,7 +126,7 @@
stw r1,GPR1(r11); \
mfspr r9,SPRN_CSRR1; \
stw r1,0(r11); \
- tovirt(r1,r11); \
+ mr r1,r11; \
rlwinm r9,r9,0,14,12; /* clear MSR_WE (necessary?) */\
stw r0,GPR0(r11); \
SAVE_4GPRS(3, r11); \
@@ -109,43 +135,18 @@
/*
* Exception prolog for machine check exceptions. This is similar to
* the critical exception prolog, except that machine check exceptions
- * have their own save area. For Book E processors, we also have a
- * reserved register (SPRG6) that is only used in machine check exceptions
- * so we can free up a GPR to use as the base for indirect access to the
- * machine check exception save area. This is necessary since the MMU
- * is always on and the save area is offset from KERNELBASE.
+ * have their stack.
*/
#define MCHECK_EXCEPTION_PROLOG \
- mtspr SPRN_SPRG6W,r8; /* SPRG6 used in machine checks */ \
- lis r8,mcheck_save@ha; \
- stw r10,mcheck_r10@l(r8); \
- stw r11,mcheck_r11@l(r8); \
- mfspr r10,SPRN_SPRG0; \
- stw r10,mcheck_sprg0@l(r8); \
- mfspr r10,SPRN_SPRG1; \
- stw r10,mcheck_sprg1@l(r8); \
- mfspr r10,SPRN_SPRG4R; \
- stw r10,mcheck_sprg4@l(r8); \
- mfspr r10,SPRN_SPRG5R; \
- stw r10,mcheck_sprg5@l(r8); \
- mfspr r10,SPRN_SPRG7R; \
- stw r10,mcheck_sprg7@l(r8); \
- mfspr r10,SPRN_PID; \
- stw r10,mcheck_pid@l(r8); \
- mfspr r10,SPRN_SRR0; \
- stw r10,mcheck_srr0@l(r8); \
- mfspr r10,SPRN_SRR1; \
- stw r10,mcheck_srr1@l(r8); \
- mfspr r10,SPRN_CSRR0; \
- stw r10,mcheck_csrr0@l(r8); \
- mfspr r10,SPRN_CSRR1; \
- stw r10,mcheck_csrr1@l(r8); \
- mfspr r8,SPRN_SPRG6R; /* SPRG6 used in machine checks */ \
+ mtspr MCHECK_SPRG,r8; \
+ BOOKE_LOAD_MCHECK_STACK; /* r8 points to the mcheck stack */\
+ stw r10,GPR10-INT_FRAME_SIZE(r8); \
+ stw r11,GPR11-INT_FRAME_SIZE(r8); \
mfcr r10; /* save CR in r10 for now */\
mfspr r11,SPRN_MCSRR1; /* check whether user or kernel */\
andi. r11,r11,MSR_PR; \
- lis r11,mcheck_stack_top@h; \
- ori r11,r11,mcheck_stack_top@l; \
+ mr r11,r8; \
+ mfspr r8,MCHECK_SPRG; \
beq 1f; \
/* COMING FROM USER MODE */ \
mfspr r11,SPRN_SPRG3; /* if from user, start at top of */\
@@ -165,7 +166,7 @@
stw r1,GPR1(r11); \
mfspr r9,SPRN_MCSRR1; \
stw r1,0(r11); \
- tovirt(r1,r11); \
+ mr r1,r11; \
rlwinm r9,r9,0,14,12; /* clear MSR_WE (necessary?) */\
stw r0,GPR0(r11); \
SAVE_4GPRS(3, r11); \
@@ -289,11 +290,11 @@
mtspr SPRN_CSRR1,r9; \
lwz r9,GPR9(r11); \
lwz r12,GPR12(r11); \
- mtspr SPRN_SPRG2,r8; /* SPRG2 only used in criticals */ \
- lis r8,crit_save@ha; \
- lwz r10,crit_r10@l(r8); \
- lwz r11,crit_r11@l(r8); \
- mfspr r8,SPRN_SPRG2; \
+ mtspr CRIT_SPRG,r8; \
+ BOOKE_LOAD_CRIT_STACK; /* r8 points to the crit stack */ \
+ lwz r10,GPR10-INT_FRAME_SIZE(r8); \
+ lwz r11,GPR11-INT_FRAME_SIZE(r8); \
+ mfspr r8,CRIT_SPRG; \
\
rfci; \
b .; \
diff -Nru a/arch/ppc/kernel/head_e500.S b/arch/ppc/kernel/head_e500.S
--- a/arch/ppc/kernel/head_e500.S 2005-03-28 14:24:24 -06:00
+++ b/arch/ppc/kernel/head_e500.S 2005-03-28 14:24:24 -06:00
@@ -33,6 +33,7 @@
*/
#include <linux/config.h>
+#include <linux/threads.h>
#include <asm/processor.h>
#include <asm/page.h>
#include <asm/mmu.h>
@@ -789,8 +790,6 @@
SYNC
rfi
-
-
/*
* SPE unavailable trap from kernel - print a message, but let
* the task use SPE in the kernel until it returns to user mode.
@@ -929,78 +928,13 @@
_GLOBAL(swapper_pg_dir)
.space 4096
+/* Reserved 4k for the critical exception stack & 4k for the machine
+ * check stack per CPU for kernel mode exceptions */
.section .bss
-/* Stack for handling critical exceptions from kernel mode */
-critical_stack_bottom:
- .space 4096
-critical_stack_top:
- .previous
-
-/* Stack for handling machine check exceptions from kernel mode */
-mcheck_stack_bottom:
- .space 4096
-mcheck_stack_top:
- .previous
-
-/*
- * This area is used for temporarily saving registers during the
- * critical and machine check exception prologs. It must always
- * follow the page aligned allocations, so it starts on a page
- * boundary, ensuring that all crit_save areas are in a single
- * page.
- */
-
-/* crit_save */
-_GLOBAL(crit_save)
- .space 4
-_GLOBAL(crit_r10)
- .space 4
-_GLOBAL(crit_r11)
- .space 4
-_GLOBAL(crit_sprg0)
- .space 4
-_GLOBAL(crit_sprg1)
- .space 4
-_GLOBAL(crit_sprg4)
- .space 4
-_GLOBAL(crit_sprg5)
- .space 4
-_GLOBAL(crit_sprg7)
- .space 4
-_GLOBAL(crit_pid)
- .space 4
-_GLOBAL(crit_srr0)
- .space 4
-_GLOBAL(crit_srr1)
- .space 4
-
-/* mcheck_save */
-_GLOBAL(mcheck_save)
- .space 4
-_GLOBAL(mcheck_r10)
- .space 4
-_GLOBAL(mcheck_r11)
- .space 4
-_GLOBAL(mcheck_sprg0)
- .space 4
-_GLOBAL(mcheck_sprg1)
- .space 4
-_GLOBAL(mcheck_sprg4)
- .space 4
-_GLOBAL(mcheck_sprg5)
- .space 4
-_GLOBAL(mcheck_sprg7)
- .space 4
-_GLOBAL(mcheck_pid)
- .space 4
-_GLOBAL(mcheck_srr0)
- .space 4
-_GLOBAL(mcheck_srr1)
- .space 4
-_GLOBAL(mcheck_csrr0)
- .space 4
-_GLOBAL(mcheck_csrr1)
- .space 4
+ .align 12
+exception_stack_bottom:
+ .space BOOKE_EXCEPTION_STACK_SIZE * NR_CPUS
+_GLOBAL(exception_stack_top)
/*
* This space gets a copy of optional info passed to us by the bootstrap
@@ -1015,5 +949,4 @@
*/
abatron_pteptrs:
.space 8
-
^ permalink raw reply
* Re: ASM formatting rules?
From: Kumar Gala @ 2005-03-28 23:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Tom Rini, linuxppc-dev list, ML linuxppc-embedded
In-Reply-To: <16968.31026.148291.626305@cargo.ozlabs.ibm.com>
Great, if my counting is correct (which may not be, since I grow up in=20=
Florida)
2 - for no space (Paul, BenH)
2 - for spaces (Tom, Dan)
2 - dont cares (Kumar, Matt)
Well, does Paul have authoritative rule here as ppc maintainer? :)
- kumar
On Mar 28, 2005, at 3:37 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
> > I'm assuming something like this (w/o spaces):
> >
> > <TAB>insn<TAB>argD,arg1,arg2
> >
> > is what we want?=A0 Just trying to get a rule documented going =
forward.
>
> Yep, that's the style we use.
>
> Paul.
^ permalink raw reply
* PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Sven Luther @ 2005-03-28 23:23 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I have been investigating the prep breakage of the sym53c8xx driver on my
powerstack II in recent kernels, and traced it to the residual data patch,
or more exactly to the whole prep_pci.c/prep_setup.c patches that where
introduced between 2.6.9-rc1 and 2.6.9-rc1-bk1. I didn't have time to find
more details as the patch is not so small, and seems to do many things, and
linux.bkbits.net seems done right now.
Mmm, after a bit more of investigation, the changeset breaking it is :
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/08/16 10:35:18-07:00 trini@kernel.crashing.org
# ppc32: On PReP, use residual data for PCI dev -> IRQ, and use it.
#
# Signed-off-by: Leigh Brown <leigh@solinno.co.uk>
# Signed-off-by: Tom Rini <trini@kernel.crashing.org>
#
# include/asm-ppc/residual.h
# 2004/08/16 10:35:09-07:00 trini@kernel.crashing.org +7 -0
# This adds a function to use the residual data to determine the IRQ
# for a given PCI device, and changes prep_pcibios_fixup() to use it.
#
# arch/ppc/platforms/residual.c
# 2004/08/16 10:35:09-07:00 trini@kernel.crashing.org +60 -0
# This adds a function to use the residual data to determine the IRQ
# for a given PCI device, and changes prep_pcibios_fixup() to use it.
#
# arch/ppc/platforms/prep_pci.c
# 2004/08/16 10:35:09-07:00 trini@kernel.crashing.org +37 -23
# This adds a function to use the residual data to determine the IRQ
# for a given PCI device, and changes prep_pcibios_fixup() to use it.
Mmm, i guess this makes sense, since it seems the sym53c8xx doesn'y find its
irq anymore or something. Tom Rini, or Leigh Brown, do you have any comments
on this one ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Kumar Gala @ 2005-03-28 23:45 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Netdev, ML linuxppc-embedded
In-Reply-To: <6b870ceb81370f10886e5b7a5943ae82@freescale.com>
Jeff,
I was wondering what the next steps where on getting Andy's PHY
abstraction layer into the kernel.
thanks
- kumar
^ permalink raw reply
* where to download montavista kernel code for mips
From: likun @ 2005-03-29 1:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 269 bytes --]
HI ALL:
I'm confused! Where can one download a kernel with montavista for mips?
They
don't seem to offer it anywhere, but surely it should be available?
Thanks
jordon
[-- Attachment #2: Type: text/html, Size: 649 bytes --]
^ permalink raw reply
* [PATCH] sleep & cpufreq problems
From: Benjamin Herrenschmidt @ 2005-03-29 3:28 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: debian-powerpc@lists.debian.org
Hi !
Here are a couple of patches against current linus bk (one was already
posted to this list) that should fix a number issues related to sleep
and wakeup, especially in conjunction with cpufreq transitions.
Please test and let me know if it fixes a problem you had, it adds a new
problem, or it has no effect, stuff still doesn't work (if it used to
work and still work, no need to bug me).
Thanks !
Patches are at:
http://gate.crashing.org/~benh/ppc32-pmac-sleep-fix.diff
http://gate.crashing.org/~benh/ppc32-cpufreq-gpio-off.diff
Thanks,
Ben.
^ permalink raw reply
* Problem when accessing variables
From: Hiep Tran @ 2005-03-29 4:11 UTC (permalink / raw)
To: ML linuxppc-embedded
In-Reply-To: <be784d868895f716feaf92e8fe93f826@freescale.com>
Hi all,
I just joint to embedded software world and I am facing with a problem
related to ppc_405-gcc compiler. My problem is my source code if compiled by
gcc compiler and run on Linux platform, everything is OK, but if my source
code is compiled with ppc_405-gcc and transfering to Power PC and to be run,
I am always facing with "pointer problem" described as follows:
I have file called "hashtable.c", which contains some functions to
manipulate a structure in C programming language (it's really a hashtable
structure, which I am implementing). These functions include adding,
removing, lookupping etc on a input pointer parameter, which point to a
hashtable structure.
I have another file called "test.c", which will use functions of hashtable,
which mentioned above. And in this file, I can manipulate my hashtable
structure by calling functions in file "hashtable.c" only. But if I access
to members of hashtable structure or hashtable's node structure directly
(without calling hashtable functions to receive these structure's members)
then my test program is always died by a invalid pointer, which is referring
to structure's member. the test.c and hashtable.c files were compiled and
linked together.
But if I copy all functions in hashtable.c and paste to test.c and then
compile, create my program by using the test.c file only the my test program
is run well.
I think my problem related to linking between object files (it's seem to me
that, pointers, which are allocated memory, or global variables declared in
this file will cause problem when access it in another file) on ppc_405-gcc
compiler because my problem is still run well on Linux computer when it was
compiled and linked by gcc compiler.
My temporary solution is I added a new function to the file hashtable.c,
this function returns data members, which reside inside node structures of
hashtable structure and I can access these data pointers without facing any
problem.
Anyone could give me any option to set to ppc_405-gcc compiler or any
solution to help to me passing the problem.
Thanks,
Hiep Tran
^ permalink raw reply
* Re: [PATCH] sleep & cpufreq problems
From: Benjamin Herrenschmidt @ 2005-03-29 4:48 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: debian-powerpc@lists.debian.org
In-Reply-To: <1112066934.6809.4.camel@gaston>
On Tue, 2005-03-29 at 13:28 +1000, Benjamin Herrenschmidt wrote:
> Hi !
>
> Here are a couple of patches against current linus bk (one was already
> posted to this list) that should fix a number issues related to sleep
> and wakeup, especially in conjunction with cpufreq transitions.
>
> Please test and let me know if it fixes a problem you had, it adds a new
> problem, or it has no effect, stuff still doesn't work (if it used to
> work and still work, no need to bug me).
>
> Thanks !
>
> Patches are at:
>
> http://gate.crashing.org/~benh/ppc32-pmac-sleep-fix.diff
> http://gate.crashing.org/~benh/ppc32-cpufreq-gpio-off.diff
I just updated the second patch, so if you got it since my last email,
please d/l it again.
Ben.
^ permalink raw reply
* Re: [PATCH] ppc44x: Remove PVR_440G* and change usages
From: Eugene Surovegin @ 2005-03-29 5:14 UTC (permalink / raw)
To: Tom Rini, Matt Porter, linuxppc-embedded
In-Reply-To: <20050321174049.GA11734@gate.ebshome.net>
On Mon, Mar 21, 2005 at 09:40:49AM -0800, Eugene Surovegin wrote:
[snip]
> > - u32 pvr = mfspr(PVR);
> > - if (pvr == PVR_440GX_RA || pvr == PVR_440GX_RB ||
> > - (pvr == PVR_440GX_RC && p->cpu > 667000000))
> > + if (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. A") == 0 ||
> > + strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. B") == 0
> > + || (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. C")
> > + == 0 && p->cpu > 667000000))
>
>
> While I applaud Tom's quest to eliminate _useless_ PVR defines I think
> this change looks strange.
>
> It substitutes simple and clear (for those who are reading this code)
> check to something more involved without good reason, IMHO.
>
> Also, it adds additional "point of failure" making this code more
> fragile. We never used those CPU ID strings anywhere in the kernel
> code before, people are used to the fact that they don't matter much
> (maybe only for user-mode) and it's possible that during some future
> "cleanup" code will break. One could say that we aren't allowed to
> change such strings because something in user-mode could break, and
> while I agree with that, I don't think it's good argument to _add_
> additional point where code could break.
While talking with galak today on IRC, he mentioned one of the reason,
why we may want to use string comparison instead of PVR.
For some chips, e.g. for 8272 family, there is NO way (even if we use
IMMR[16-31] and REV_NUM in addition to PVR) to detect correctly CPU
(which I think is pretty lame, but I digress :). For such cases, board
port can "fixup" CPU name, if this information can be implied by the
board type/revision/etc.
So, I think having a way to specify/name/detect CPU which is more
general and even can solve some real problems, is beneficial.
Therefore, I don't object anymore to such changes :).
--
Eugene
^ permalink raw reply
* RE: Problem running Linux 2.6.11 on MPC8272ADS
From: Bastos Fernandez Alexandre @ 2005-03-29 6:29 UTC (permalink / raw)
To: 'Walter L. Wimer III'; +Cc: linuxppc-embedded
Hi,
>From "linux/arch/ppc/platforms/pq2ads.h"
#define BCSR_ADDR ((uint) 0xf4500000)
>From "u-boot/include/configs/MPC8260ADS.h"
#define CFG_BCSR 0xF4500000
So ...
Which version of u-boot and/or linux tree are you using?
With linuxppc-2.5 and u-boot 1.2 everything works fine for me.
Maybe Mike's problem is other. Maybe not. :-)
Best regards,
Alex
> -----Original Message-----
> From: Walter L. Wimer III [SMTP:walt.wimer@timesys.com]
> Sent: Monday, March 28, 2005 6:07 PM
> To: Mike Rapoport
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS
>
>
> Hi Mike,
>
> I had the same "hang" experience. The file arch/ppc/platforms/pq2ads.c
> contains the following function:
>
> void __init
> m82xx_board_setup(void)
> {
> /* Enable the 2nd UART port */
> *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;
> }
>
>
> I had to ifdef-out the assignment statement above. It appears that the
> definition for BCSR_ADDR in the kernel code differs from what U-Boot is
> using, and that area of memory isn't properly mapped into the kernel
> address space this early in the boot sequence. As a result, I was
> getting an Oops() before the console was even enabled (I could see the
> Oops message by examining the kernel's printk log buffer using a
> BDI-2000 hardware debugger).
>
>
>
> Good luck,
>
> Walt Wimer
> TimeSys Corporation
>
>
>
>
> On Sun, 2005-03-27 at 11:31 +0200, Mike Rapoport wrote:
> > Hi,
> > I'm trying to bring up the Linux 2.6.11 on MPC8272ADS and it seem to
> > hang up at the very beginning.
> > I use ads8272_defconfig and then enable console on SCC:
> >
> > CONFIG_SERIAL_CPM=y
> > CONFIG_SERIAL_CPM_CONSOLE=y
> > CONFIG_SERIAL_CPM_SCC1=y
> >
> >
> > when I boot the kernel from the u-boot the system hangs up right after
> > the kernel decompression.
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: ASM formatting rules?
From: Gabriel Paubert @ 2005-03-29 8:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Tom Rini, ML linuxppc-embedded, Paul Mackerras, linuxppc-dev list
In-Reply-To: <1112048510.5410.60.camel@gaston>
On Tue, Mar 29, 2005 at 08:21:50AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2005-03-28 at 10:44 -0600, Kumar Gala wrote:
> > Guys,
> >
> > While this is not overly important to me, I was wondering if we had any
> > rules related to formatting of assembly files. We seem to have code
> > formatted with and without spaces in the args.
> >
> > I'm assuming something like this (w/o spaces):
> >
> > <TAB>insn<TAB>argD,arg1,arg2
> >
> > is what we want? Just trying to get a rule documented going forward.
>
> I used to have argD, arg1, arg2 but since everything else was "compact",
> I now tend to adapt to everything else ;)
Assembly is not C! I don't like the space after the comma in
assembly, but can adapt to (almost) any style.
For the record, the biggest file of PPC assembly I wrote
(the real mode x86 emulator to initialize graphics board
through BIOS emulation) is really atypical:
1) it has two tabs before the opcode, because it must
accomodate really_long_labels and a single tab is not enough.
2) only a space between the opcode and the operands, but many
registers have fixed uses and have mnemonic names through #defines.
This helps a lot for readability and maintainability. See 4)
for the reason.
3) no space after the comma between operands.
4) Sometimes several instructions separated by a semicolon in
the same line, but only the first instruction may have a label.
That's because at the time I wanted to see as much as possible
on a small screen. But this does not mix well with putting
tabs between instruction and operands, hence 2).
I don't think these rules ar generally applicable to
assembly files, these were specific rules which matched
my needs for this file (5000 lines).
Gabriel
^ permalink raw reply
* Re: PCI support under 2.6.11.4 on MPC8272ADS ???
From: Clemens Koller @ 2005-03-29 8:38 UTC (permalink / raw)
To: Wimer, Walt, linuxppc-embedded
In-Reply-To: <1111705036.15834.29.camel@excalibur.timesys.com>
Hi Walt!
> Using Vitaly's 2.4-based patch below as a starting point, I've been
> adding PCI support to 2.6.11.4 for the MPC8272ADS board.
>
> The good news is that I think I have PCI interrupts pretty well sorted
> out, and I see *something* half-way reasonable from "lspci".
>
> The bad news is that neither of the ethernet cards that I'm trying will
> actually work, and I see some very weird behavior with PCI configuration
> space:
>
> Card 1: Some Realtek RTL8139D-based card
> Card 2: NETGEAR FA311 (National Semi DP83815 chip)
>
> With either card installed alone, both U-Boot and my kernel identify the
> cards correctly in PCI configuration space.
>
> With *both* cards installed, both U-Boot and my kernel see the Realtek-
> based card correctly, but the NETGEAR card has a corrupted Vendor ID
> (e.g. 0x1000 or 0x1003 instead of the correct 0x100b). This happens
> regardless of which PCI slots I use for the cards (I've tried virtually
> every combination). This smells of a power problem or something to me.
Check your ADx-IDSEL connections (resistors, 220 Ohms) on the PCI Bus.
I had _two_ AD lines connected to _one_ IDSEL which means that two
AD lines are 'shorted' over 440Ohm which lead to data corruption on the
PCI bus. Check your schematics and the boards.
Maybe one of your card's PCI pad drive strength (like with the SM501
Voyager GX (where it is programmable)) isn't strong enough to drive
against the resistors in between the AD lines (which would explain that
the problems get worse with 'more' cards plugged in).
> And again, even with either card alone, the drivers have serious
> problems talking to the cards. I get various error messages from
> the drivers and I see badly mangled packets on the wire. It's also
> not uncommon for the whole system to freeze...
Smells like data corruption on the bus... the behaviour you describe
is exactly as on mine system. (MPC8540 with SM501 Graphics Board
and Promise IDE Ctrl. on PCI)
Best greets,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: MPC885 CryptoApi support.
From: Bryan O'Donoghue @ 2005-03-29 10:23 UTC (permalink / raw)
To: bdonadt; +Cc: 'linuxppc-embedded '
In-Reply-To: <NEBBIHDFOLIPIPJAKJAMMELCGEAA.bdonadt@arabellasw.com>
Bruce Donadt wrote:
> To answer the original question. The code is provided under a GPL license to
> companies that purchase a subscription to the Arabella Linux distribution.
> We have invested many man months in developing a commercial grade security
> solution for the PowerQUICCs and all of it has been written from the ground
> up. You are correct when you say that none of this is included in our "free"
> evaluation kit.
>
> Best Regards,
>
> Bruce
Don't mean to start an argument or unnecessarily continue a discussion,
Bruce, but, GPL=/the right to fork/.
If it is the case that you have provided a GPL-Arabella-Linux-Kernel, to
a customer and all the code is GPL compliant, then that customer, is
*free* to fork and/or redistribute that code, which seems like a bit of
an oxymoron, for a commercial offering !
--
Best
Bryan
^ permalink raw reply
* Re: MPC885 CryptoApi support.
From: Wolfgang Denk @ 2005-03-29 10:43 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: bdonadt, 'linuxppc-embedded '
In-Reply-To: <42492C93.2060906@eircom.net>
In message <42492C93.2060906@eircom.net> you wrote:
>
> If it is the case that you have provided a GPL-Arabella-Linux-Kernel, to
> a customer and all the code is GPL compliant, then that customer, is
> *free* to fork and/or redistribute that code, which seems like a bit of
> an oxymoron, for a commercial offering !
Maybe we should start a collect to buy one "license" and put it on a
FTP server :-)
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"I haven't lost my mind - it's backed up on tape somewhere."
^ permalink raw reply
* Re: MPC885 CryptoApi support.
From: Eran Mann @ 2005-03-29 10:50 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: bdonadt, 'linuxppc-embedded '
In-Reply-To: <20050329104340.70E0EC108D@atlas.denx.de>
Wolfgang Denk wrote:
> In message <42492C93.2060906@eircom.net> you wrote:
>
>>If it is the case that you have provided a GPL-Arabella-Linux-Kernel, to
>>a customer and all the code is GPL compliant, then that customer, is
>>*free* to fork and/or redistribute that code, which seems like a bit of
>>an oxymoron, for a commercial offering !
>
>
> Maybe we should start a collect to buy one "license" and put it on a
> FTP server :-)
>
> Best regards,
>
> Wolfgang Denk
>
Sure, and while we're at it, why not do the same for MontaVista kernel,
Metrowerks kernel, etc...
--
Eran Mann
MRV International
www.mrv.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