* Re: IPSec kernel oops on ppc64
From: Paul Mackerras @ 2006-08-31 0:57 UTC (permalink / raw)
To: Joy Latten; +Cc: jmorris, herbert, netdev, anton, linuxppc-dev, gcwilson, davem
In-Reply-To: <200608301636.k7UGaQY5002569@faith.austin.ibm.com>
Joy Latten writes:
> The good news is that the pings worked great!
> So perhaps ESP is working ok with ICMP.
>
> But when I tried to do sftp, I still got the oops.
> I don't think TCP and ESP are working.
You're hitting the BUG_ON(len) at line 611 of net/xfrm/xfrm_algo.c.
Is that the same thing that happened without the patch to memcpy, or
was that a different oops?
Paul.
^ permalink raw reply
* Re: DS1302 driver for powerpc
From: Matt Porter @ 2006-08-31 1:11 UTC (permalink / raw)
To: Chun Chung Lo; +Cc: linuxppc-embedded
In-Reply-To: <A7B1E4DD46AA7046A4398F745240F29402737D5E@ASPROEXG.astri.local>
On Thu, Aug 31, 2006 at 08:51:22AM +0800, Chun Chung Lo wrote:
>
> Hi,
>
> Thanks for your help.
>
> But I also do not have this driver for 83xx. (as my linux is comes from
> Montavista)
The 83xx reference was a hypothetical. There is no 83xx driver for the
ds1302.
> Could you mind providing me a link / or a source of such driver for me
> to reference ?
My advice is to port the cris DS1302 driver to your board-specific
GPIO configuration.
-Matt
^ permalink raw reply
* RE: DS1302 driver for powerpc
From: Chun Chung Lo @ 2006-08-31 1:03 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
Hi,
That's good. I also started to work on it.=0D
Thanks for your quick reply.
Best regards,
Lo Chun Chung
-----Original Message-----
From: Matt Porter [mailto:mporter@embeddedalley.com]=0D
Sent: Thursday, 31 August, 2006 9:12 AM
To: Chun Chung Lo
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: DS1302 driver for powerpc
On Thu, Aug 31, 2006 at 08:51:22AM +0800, Chun Chung Lo wrote:
>=0D
> Hi,
>=0D
> Thanks for your help.
>=0D
> But I also do not have this driver for 83xx. (as my linux is comes=0D
> from
> Montavista)
The 83xx reference was a hypothetical. There is no 83xx driver for the
ds1302.
=0D
> Could you mind providing me a link / or a source of such driver for me
> to reference ?
My advice is to port the cris DS1302 driver to your board-specific GPIO
configuration.=0D
-Matt
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* Re: 2 Ethernet port operating in a PPC405EP system
From: Matt Porter @ 2006-08-31 1:19 UTC (permalink / raw)
To: Otto Solares; +Cc: linuxppc-embedded
In-Reply-To: <20060830182303.GB25352@guug.org>
On Wed, Aug 30, 2006 at 01:23:03PM -0500, Otto Solares wrote:
> Don't repeat the same mistake as the MediaMVP, it uses the same
> processor and same kernel version, it sucks badly...
FWIW, MediaMVP doesn't use the same processor. It has an
STBx25xx which is quite different from a 405EP. It is
the same 405 core at least.
-Matt
^ permalink raw reply
* Re: IPSec kernel oops on ppc64
From: Herbert Xu @ 2006-08-31 1:59 UTC (permalink / raw)
To: Joy Latten; +Cc: jmorris, netdev, anton, linuxppc-dev, gcwilson, paulus, davem
In-Reply-To: <200608301636.k7UGaQY5002569@faith.austin.ibm.com>
On Wed, Aug 30, 2006 at 11:36:26AM -0500, Joy Latten wrote:
>
> I tried the patch on the following:
> linux-2.6.17 + patch-2.6.18-rc1
>
> The good news is that the pings worked great!
> So perhaps ESP is working ok with ICMP.
>
> But when I tried to do sftp, I still got the oops.
> I don't think TCP and ESP are working.
Interesting. We were previously off by 28 bytes, now we're off by 8 :)
Could you please do a test by deleting the defines for
__HAVE_ARCH_MEMMOVE and __HAVE_ARCH_MEMCPY from include/asm-powerpc
to see if using the generic routines help?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* RE: [PATCH] corrected PCI interrupt sense values to level low inmpc8349emds.dts
From: Liu Dave-r63238 @ 2006-08-31 2:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Phillips Kim-R1AAHA
In-Reply-To: <E8F8F71E-CEB8-4CEE-ACB7-AB602AB410BF@kernel.crashing.org>
<snip>
>=20
> > Where these IDSEL 0x15~0x18 come from on 8349EMDS board?
> > Please expain it.
>=20
> This is from the docs on the PMC-PCI expansion boards that=20
> state what IDSELs are used and how they are wired up.
Maybe you misunderstand me, I know that, the IDSEL is determined
by hardware design, I look up the schematic, only AD17/18/19 are
connected to PCI SLOT, that is IDSEL 0x11~0x13, I cannot find the
IDSEL 0x15~0x18 are impemented in the PIB. The IDSEL 0x15~0x18
actually are not existing.
-DAve
^ permalink raw reply
* Re: IPSec kernel oops on ppc64
From: Paul Mackerras @ 2006-08-31 3:22 UTC (permalink / raw)
To: Herbert Xu
Cc: jmorris, netdev, anton, linuxppc-dev, gcwilson, Joy Latten, davem
In-Reply-To: <20060831015942.GA27423@gondor.apana.org.au>
Herbert Xu writes:
> Interesting. We were previously off by 28 bytes, now we're off by 8 :)
You missed a couple of 'beqlr' instructions (branch if equal to LR).
I'd be interested to know if it still fails with the patch below.
Thanks,
Paul.
diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S
index fd66acf..7173ba9 100644
--- a/arch/powerpc/lib/memcpy_64.S
+++ b/arch/powerpc/lib/memcpy_64.S
@@ -11,6 +11,7 @@ #include <asm/ppc_asm.h>
.align 7
_GLOBAL(memcpy)
+ std r3,48(r1) /* save destination pointer for return value */
mtcrf 0x01,r5
cmpldi cr1,r5,16
neg r6,r3 # LS 3 bits = # bytes to 8-byte dest bdry
@@ -38,7 +39,7 @@ _GLOBAL(memcpy)
stdu r9,16(r3)
bdnz 1b
3: std r8,8(r3)
- beqlr
+ beq 3f
addi r3,r3,16
ld r9,8(r4)
.Ldo_tail:
@@ -53,7 +54,8 @@ _GLOBAL(memcpy)
2: bf cr7*4+3,3f
rotldi r9,r9,8
stb r9,0(r3)
-3: blr
+3: ld r3,48(r1) /* return dest pointer */
+ blr
.Lsrc_unaligned:
srdi r6,r5,3
@@ -115,7 +117,7 @@ _GLOBAL(memcpy)
5: srd r12,r9,r11
or r12,r8,r12
std r12,24(r3)
- beqlr
+ beq 4f
cmpwi cr1,r5,8
addi r3,r3,32
sld r9,r9,r10
@@ -167,4 +169,5 @@ _GLOBAL(memcpy)
3: bf cr7*4+3,4f
lbz r0,0(r4)
stb r0,0(r3)
-4: blr
+4: ld r3,48(r1) /* return dest pointer */
+ blr
^ permalink raw reply related
* RE: [PATCH] corrected PCI interrupt sense values to level lowinmpc8349emds.dts
From: Li Yang-r58472 @ 2006-08-31 3:28 UTC (permalink / raw)
To: Liu Dave-r63238, Kumar Gala; +Cc: linuxppc-dev, Phillips Kim-R1AAHA
In-Reply-To: <995B09A8299C2C44B59866F6391D263511BCA1@zch01exm21.fsl.freescale.net>
> <snip>
> >=20
> > > Where these IDSEL 0x15~0x18 come from on 8349EMDS board?
> > > Please expain it.
> >=20
> > This is from the docs on the PMC-PCI expansion boards that=20
> state what=20
> > IDSELs are used and how they are wired up.
>=20
> Maybe you misunderstand me, I know that, the IDSEL is=20
> determined by hardware design, I look up the schematic, only=20
> AD17/18/19 are connected to PCI SLOT, that is IDSEL=20
> 0x11~0x13, I cannot find the IDSEL 0x15~0x18 are impemented=20
> in the PIB. The IDSEL 0x15~0x18 actually are not existing.
These IDSELs are used by PCI Expansion Adaptor Board which has 4 PCI
slots for PCI1.
- Leo
^ permalink raw reply
* Re: IPSec kernel oops on ppc64
From: Herbert Xu @ 2006-08-31 3:53 UTC (permalink / raw)
To: Paul Mackerras
Cc: jmorris, netdev, anton, linuxppc-dev, gcwilson, Joy Latten, davem
In-Reply-To: <17654.21983.691176.397891@cargo.ozlabs.ibm.com>
Hi Paul:
On Thu, Aug 31, 2006 at 01:22:07PM +1000, Paul Mackerras wrote:
>
> You missed a couple of 'beqlr' instructions (branch if equal to LR).
> I'd be interested to know if it still fails with the patch below.
Yes that'd do it.
BTW, did you see the "cmpldi r1,..." stuff in the code? That's a typo,
right?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] fbdev: Fix crashes in various fbdev's blank routines
From: Benjamin Herrenschmidt @ 2006-08-31 4:04 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds
Cc: linuxppc-dev list, Linux Fbdev development list, Olaf Hering
The backlight changes that went in 2.6.18 had a bug where they could
cause the kernel to access an unitialized pointer when blanking if there
is no backlight control on a machine. The bug affects atyfb, aty128fb,
nvidiafb and rivafb. radeonfb seems to be ok. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This is a 2.6.18 regression, please merge before release ! It breaks a
number of non-laptop powermacs (among others I suppose).
Index: linux-work/drivers/video/aty/aty128fb.c
===================================================================
--- linux-work.orig/drivers/video/aty/aty128fb.c 2006-08-17 09:26:21.000000000 +1000
+++ linux-work/drivers/video/aty/aty128fb.c 2006-08-31 13:56:11.000000000 +1000
@@ -1800,6 +1800,9 @@ static struct backlight_properties aty12
static void aty128_bl_set_power(struct fb_info *info, int power)
{
+ if (info->bl_dev == NULL)
+ return;
+
mutex_lock(&info->bl_mutex);
up(&info->bl_dev->sem);
info->bl_dev->props->power = power;
@@ -1828,7 +1831,7 @@ static void aty128_bl_init(struct aty128
bd = backlight_device_register(name, par, &aty128_bl_data);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
- printk("aty128: Backlight registration failed\n");
+ printk(KERN_WARNING "aty128: Backlight registration failed\n");
goto error;
}
Index: linux-work/drivers/video/aty/atyfb_base.c
===================================================================
--- linux-work.orig/drivers/video/aty/atyfb_base.c 2006-08-17 09:26:21.000000000 +1000
+++ linux-work/drivers/video/aty/atyfb_base.c 2006-08-31 13:55:43.000000000 +1000
@@ -2199,6 +2199,9 @@ static struct backlight_properties aty_b
static void aty_bl_set_power(struct fb_info *info, int power)
{
+ if (info->bl_dev == NULL)
+ return;
+
mutex_lock(&info->bl_mutex);
up(&info->bl_dev->sem);
info->bl_dev->props->power = power;
@@ -2223,7 +2226,7 @@ static void aty_bl_init(struct atyfb_par
bd = backlight_device_register(name, par, &aty_bl_data);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
- printk("aty: Backlight registration failed\n");
+ printk(KERN_WARNING "aty: Backlight registration failed\n");
goto error;
}
Index: linux-work/drivers/video/nvidia/nv_backlight.c
===================================================================
--- linux-work.orig/drivers/video/nvidia/nv_backlight.c 2006-08-17 09:26:22.000000000 +1000
+++ linux-work/drivers/video/nvidia/nv_backlight.c 2006-08-31 13:58:47.000000000 +1000
@@ -112,6 +112,8 @@ static struct backlight_properties nvidi
void nvidia_bl_set_power(struct fb_info *info, int power)
{
+ if (info->bl_dev == NULL)
+ return;
mutex_lock(&info->bl_mutex);
up(&info->bl_dev->sem);
info->bl_dev->props->power = power;
@@ -140,7 +142,7 @@ void nvidia_bl_init(struct nvidia_par *p
bd = backlight_device_register(name, par, &nvidia_bl_data);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
- printk("nvidia: Backlight registration failed\n");
+ printk(KERN_WARNING "nvidia: Backlight registration failed\n");
goto error;
}
Index: linux-work/drivers/video/riva/fbdev.c
===================================================================
--- linux-work.orig/drivers/video/riva/fbdev.c 2006-08-17 09:26:22.000000000 +1000
+++ linux-work/drivers/video/riva/fbdev.c 2006-08-31 13:58:49.000000000 +1000
@@ -354,6 +354,9 @@ static struct backlight_properties riva_
static void riva_bl_set_power(struct fb_info *info, int power)
{
+ if (info->bl_dev == NULL)
+ return;
+
mutex_lock(&info->bl_mutex);
up(&info->bl_dev->sem);
info->bl_dev->props->power = power;
@@ -382,7 +385,7 @@ static void riva_bl_init(struct riva_par
bd = backlight_device_register(name, par, &riva_bl_data);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
- printk("riva: Backlight registration failed\n");
+ printk(KERN_WARNING "riva: Backlight registration failed\n");
goto error;
}
^ permalink raw reply
* Re: IPSec kernel oops on ppc64
From: Paul Mackerras @ 2006-08-31 4:25 UTC (permalink / raw)
To: Herbert Xu
Cc: jmorris, netdev, anton, linuxppc-dev, gcwilson, Joy Latten, davem
In-Reply-To: <20060831035346.GA28306@gondor.apana.org.au>
Herbert Xu writes:
> BTW, did you see the "cmpldi r1,..." stuff in the code? That's a typo,
> right?
Yes it is a typo, but fixing it is lower priority since both r1 and
cr1 equal 1.
Paul.
^ permalink raw reply
* Please pull powerpc.git 'merge' branch
From: Paul Mackerras @ 2006-08-31 4:34 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some more PowerPC updates for 2.6.18.
I have included the full commit messages this time. There are
(unfortunately) quite a few commits, because:
* People have been finding bugs. :P This includes the fix for Olaf's
problem where time wasn't advancing, plus one found recently where
memcpy not returning the correct value was causing an oops in the
ipsec code.
* Some of the embedded board maintainers have only just caught up with
Ben H's irq rework that went in near the end of the merge window.
Since their platforms don't compile without the fixes, and changes
in their code aren't going to affect a lot of users, I put them in.
* I have included some "device tree source" files, which are
essentially documentation as far as the kernel is concerned. They
don't directly affect any kernel code, but can be useful as a
reference when reading the code. (They would normally be compiled
to a binary form and supplied by board firmware to the kernel at boot.)
Thanks,
Paul.
Documentation/powerpc/booting-without-of.txt | 6
arch/powerpc/Kconfig | 20 -
arch/powerpc/boot/dts/mpc7448hpc2.dts | 190 ++++++
arch/powerpc/boot/dts/mpc8349emds.dts | 328 +++++++++++
arch/powerpc/configs/mpc834x_mds_defconfig | 0
arch/powerpc/kernel/fpu.S | 5
arch/powerpc/kernel/irq.c | 84 ++-
arch/powerpc/kernel/pci_64.c | 11
arch/powerpc/kernel/ppc_ksyms.c | 4
arch/powerpc/kernel/prom_init.c | 10
arch/powerpc/kernel/prom_parse.c | 17 -
arch/powerpc/kernel/smp-tbsync.c | 5
arch/powerpc/kernel/time.c | 25 -
arch/powerpc/lib/memcpy_64.S | 11
arch/powerpc/mm/44x_mmu.c | 4
arch/powerpc/platforms/83xx/mpc834x_itx.c | 49 --
arch/powerpc/platforms/83xx/mpc834x_sys.c | 56 --
arch/powerpc/platforms/83xx/mpc83xx.h | 1
arch/powerpc/platforms/83xx/pci.c | 9
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 26 -
arch/powerpc/platforms/86xx/pci.c | 3
arch/powerpc/platforms/embedded6xx/Kconfig | 1
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 2
arch/powerpc/sysdev/Makefile | 4
arch/powerpc/sysdev/ipic.c | 303 +++++++---
arch/powerpc/sysdev/ipic.h | 23 +
arch/powerpc/sysdev/mpic.c | 223 +++++--
arch/ppc/kernel/smp-tbsync.c | 7
arch/ppc/syslib/Makefile | 2
arch/ppc/syslib/ipic.c | 646 +++++++++++++++++++++
arch/ppc/syslib/ipic.h | 47 ++
include/asm-powerpc/io.h | 7
include/asm-powerpc/ipic.h | 12
include/asm-powerpc/mpc86xx.h | 3
include/asm-powerpc/mpic.h | 125 ++++
include/asm-powerpc/prom.h | 4
include/asm-powerpc/time.h | 4
37 files changed, 1934 insertions(+), 343 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc7448hpc2.dts
create mode 100644 arch/powerpc/boot/dts/mpc8349emds.dts
rename arch/powerpc/configs/{mpc834x_sys_defconfig => mpc834x_mds_defconfig} (100%)
create mode 100644 arch/ppc/syslib/ipic.c
create mode 100644 arch/ppc/syslib/ipic.h
commit d0027bf09f09d95a23b8f476ba8cea28f2576781
Author: Paul Mackerras <paulus@samba.org>
Date: Thu Aug 31 13:22:58 2006 +1000
[POWERPC] Fix return value from memcpy
As pointed out by Herbert Xu <herbert@gondor.apana.org.au>, our
memcpy implementation didn't return the destination pointer as its
return value, and there is code in the kernel that expects that.
This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit e7498656b5e2e9e3806d263fecc90b2707d02093
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed Aug 30 17:11:34 2006 +1000
[POWERPC] iseries: Define insw et al. so libata/ide will compile
These are build fixes that enable (for example) libata and the ide
code to actually build on iSeries. The associated hardware will never
be supported on legacy iSeries, so the code paths don't actually need
to work, but it is useful (especially for a combined kernel) if the
code can build.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 467c37801c453849a2fe243c3226476ee3985868
Author: Paul Mackerras <paulus@samba.org>
Date: Wed Aug 30 16:10:47 2006 +1000
[POWERPC] Fix irq enable/disable in smp_generic_take_timebase
Eran Ben-Avi <eranpublic@yahoo.com> pointed out that the arch/ppc version
of smp_generic_take_timebase disables interrupts on entry but exits without
restoring them. However, both it and the arch/powerpc version have another
problem, which is that they use local_irq_disable/enable rather than
local_irq_save/restore, and they are called with interrupts disabled.
This fixes both problems; it changes a return to a break in the arch/ppc
version, and changes both versions to use local_irq_save/restore.
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit e0d872d536bb93335d5905b09fe374a163486d43
Author: Paul Mackerras <paulus@samba.org>
Date: Wed Aug 30 15:55:32 2006 +1000
[POWERPC] Fix problem with time not advancing on 32-bit platforms
This fixes a problem introduced in 5db9fa9593e2ff69f2b95f9d59229dc4faaa564d.
The last_jiffy per-cpu variable is only 32 bits on 32-bit machines, but it
was being compared with a 64-bit quantity (tb_next_jiffy), which resulted in
time not advancing.
This fixes it by changing last_jiffy to be 64 bits on all platforms. With
this, we no longer need tb_last_stamp as a 32-bit version of tb_last_jiffy,
so this gets rid of tb_last_stamp and we just use tb_last_jiffy instead.
This also fixes a bug when the boot cpu is not online, because using
tb_last_stamp could have caused the wrong timebase origin value to be used
when calculating the time of day.
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit fea23bfefb4e98efd3c36f00ccc0b60281dc99da
Author: Paul Mackerras <paulus@samba.org>
Date: Wed Aug 30 14:45:35 2006 +1000
[POWERPC] Restore copyright notice in arch/powerpc/kernel/fpu.S
This code got moved from head.S but the copyright notice on head.S didn't
get transferred with it. Noticed by Cort Dougan <cort@fsmlabs.com>.
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 11e9ed43ca8a741c2858c33d12120cf8817d3bff
Author: Will Schmidt <will_schmidt@vnet.ibm.com>
Date: Fri Aug 25 15:46:59 2006 -0500
[POWERPC] Fix up ibm_architecture_vec definition
This problem was noticed by one of the Phyp firmware folks.
Our ibm,client-architecture-support call was failing.
This corrects the vector length parameters being passed in.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 006b64de607f895de2ba1e21d3179cddf059128f
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri Aug 25 14:46:23 2006 +1000
[POWERPC] Make OF irq map code detect more error cases
Device-tree bugs on js20 with some versions of SLOF were causing the
interrupt for IDE to not be parsed correctly and fail to boot. This
patch adds a bit more sanity checking to the parser to detect some of
those errors and fail instead of returning bogus information. The
powerpc PCI code can then trigger a fallback that works on those
machines.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 7233593b7844c2db930594ee9c0c872a6900bfcc
Author: Zang Roy-r61911 <tie-fei.zang@freescale.com>
Date: Fri Aug 25 14:16:30 2006 +1000
[POWERPC] Support for "weird" MPICs and fixup mpc7448_hpc2
This adds a new hardware information table for mpic. This enables
the mpic code to deal with mpic controllers with different register
layouts and hardware behaviours.
This introduces CONFIG_MPIC_WEIRD. For boards with non standard mpic
controllers, select CONFIG_MPIC_WEIRD and add its hardware information
in the mpic_infos[] array.
TSI108/109 PIC takes the first index of weird hardware information
table. :) The table can be extended. The Tsi108/109 PIC looks like
standard OpenPIC but, in fact, is different in register mapping and
behavior.
The patch does not affect the behavior of standard mpic. If
CONFIG_MPIC_WEIRD is not defined, the code is essentially identical to
the current code.
[benh@kernel.crashing.org:
This patch is a slightly cleaned up version of Zang Roy's support for
the TSI108 MPIC variant. It also fixes up MPC7448_hpc2 to use the new
version of the type macros and changes the way MPIC is selected in
Kconfig to better match what is done for other system devices.
]
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 3efbdd136e52ee4028b5bb5b848a6043cf61cd6e
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed Aug 30 08:58:00 2006 +1000
[POWERPC] Fix MPIC sense codes in documentation
The booting-without-of.txt had incorrect definition for the sense codes
for an OpenPIC controller
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 8ec8f2e85c6b88b4a1641eb3902275bcf2c6d60a
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon Aug 28 11:17:37 2006 +1000
[POWERPC] Fix performance regression in IRQ radix tree locking
When reworking the powerpc irq code, I figured out that we were using
the radix tree in a racy way. As a temporary fix, I put a spinlock in
there. However, this can have a significant impact on performances. This
patch reworks that to use a smarter technique based on the fact that
what we need is in fact a rwlock with extremely rare writers (thus
optimized for the read path).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 4b3afca9345f5beb9c607faeb2aef4f91dd91a13
Author: Zang Roy-r61911 <tie-fei.zang@freescale.com>
Date: Fri Aug 25 16:43:25 2006 +0800
[POWERPC] Add mpc7448hpc2 device tree source file
This patch adds the mpc7448hpc2 device tree source file.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 1b9a93eb4638dcde0c3af42fd6c05e3911baa7db
Author: Kim Phillips <kim.phillips@freescale.com>
Date: Tue Aug 29 18:13:31 2006 -0500
[POWERPC] Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts
Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit f1f17716d13bfb709809a3f5c84bda105b646b9e
Author: Kim Phillips <kim.phillips@freescale.com>
Date: Fri Aug 25 11:59:22 2006 -0500
[POWERPC] modify mpc83xx platforms to use new IRQ layer
This fixes MPC834x MDS (formerly SYS) and ITX platform code to get IRQ data (including PCI) from the device tree, and to use the new IPIC code.
renamed defconfig (sys -> mds), left one redundant NULL assignment in mpc83xx_pcibios_fixup to keep the compiler happy.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit b9f0f1bb2bcaae96dd3267f6bd3ad1ca44a1f5ad
Author: Kim Phillips <kim.phillips@freescale.com>
Date: Fri Aug 25 11:59:07 2006 -0500
[POWERPC] Adapt ipic driver to new host_ops interface, add set_irq_type to set IRQ sense
This converts ipic code to Benh's IRQ mods. For the IPIC, IRQ sense values in the device tree equal those in include/linux/irq.h; that's 8 for low assertion (most internal IRQs on mpc83xx), and 2 for high-to-low change.
spinlocks added to [un]mask, ack operations; default handler and type now set in host_map; and redundant condition check eliminated.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit bf4152dd7ccb6c060d786200a893dfe30193a07f
Author: Kim Phillips <kim.phillips@freescale.com>
Date: Fri Aug 25 11:58:53 2006 -0500
[POWERPC] back up old school ipic.[hc] to arch/ppc
Keep from breaking 83xx arch/ppc build. Back up old school arch/powerpc/sysdev/ipic.[hc] to arch/ppc/syslib.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit c85c41ad73c6db4cf4cc98c595cc5e2fdbdb53d5
Author: Jon Loeliger <jdl@freescale.com>
Date: Thu Aug 17 14:27:57 2006 -0500
[POWERPC] Use mpc8641hpcn PIC base address from dev tree.
After going through the trouble of setting up the PIC base
address in the pic@40000 device tree node, use it instead
of the obsolete hard-coded value.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 5dc599c206ad50e1b190edfbc98b7cf8ce361003
Author: Jon Loeliger <jdl@freescale.com>
Date: Tue Aug 15 16:19:02 2006 -0500
[POWERPC] Allow MPC8641 HPCN to build with CONFIG_PCI disabled too.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 054389f114fc55d525926b55e82b473b783a7d77
Author: Matt Porter <mporter@embeddedalley.com>
Date: Fri Aug 4 11:44:01 2006 -0500
[POWERPC] Fix powerpc 44x_mmu build
The PIN_SIZE definition name changed, update 44x_mmu.c accordingly.
Signed-off-by: Matt Porter <mporter@embeddedalley.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit af07ac276af6eec5111a6567cb7eaf4d222bd332
Author: Matt Porter <mporter@embeddedalley.com>
Date: Fri Aug 4 11:41:51 2006 -0500
[POWERPC] Remove flush_dcache_all export
Removes the flush_dcache_all export for non coherent platforms.
We removed the last in-kernel user of this years ago in arch/ppc
so it no longer serves a purpose. Plus, it breaks the build
at the moment.
Signed-off-by: Matt Porter <mporter@embeddedalley.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* RE: [PATCH] corrected PCI interrupt sense values to level lowinmpc8349emds.dts
From: Liu Dave-r63238 @ 2006-08-31 4:46 UTC (permalink / raw)
To: Li Yang-r58472, Kumar Gala; +Cc: linuxppc-dev, Phillips Kim-R1AAHA
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC9B2@zch01exm20.fsl.freescale.net>
> >=20
> > Maybe you misunderstand me, I know that, the IDSEL is determined by=20
> > hardware design, I look up the schematic, only
> > AD17/18/19 are connected to PCI SLOT, that is IDSEL 0x11~0x13, I=20
> > cannot find the IDSEL 0x15~0x18 are impemented in the PIB.=20
> The IDSEL=20
> > 0x15~0x18 actually are not existing.
>=20
> These IDSELs are used by PCI Expansion Adaptor Board which=20
> has 4 PCI slots for PCI1.
Oh...The PCI expansion adaptor board. I see.
I have not ever seen the board.
-DAve
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Linus Torvalds @ 2006-08-31 4:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17654.26321.851991.285528@cargo.ozlabs.ibm.com>
On Thu, 31 Aug 2006, Paul Mackerras wrote:
>
> [POWERPC] Fix problem with time not advancing on 32-bit platforms
I had just previously applied this to my tree, but apparently you used the
exact same patch, so it all merged fine.
Pulled and pushed out,
Linus
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Nishanth Aravamudan @ 2006-08-31 6:00 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-mm, lnxninja, Andi Kleen, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0608301401290.4217@schroedinger.engr.sgi.com>
On 30.08.2006 [14:04:40 -0700], Christoph Lameter wrote:
> > I took out the mlock() call, and I get the same results, FWIW.
>
> What zones are available on your box? Any with HIGHMEM?
How do I tell the available zones from userspace? This is ppc64 with
about 64GB of memory total, it looks like. So, none of the nodes
(according to /sys/devices/system/node/*/meminfo) have highmem.
> Also what kernel version are we talking about? Before 2.6.18?
The SuSE default, 2.6.16.21 -- I thought I mentioned that in one of my
replies, sorry.
Tim and I spent most of this afternoon debugging the huge_zonelist()
callpath with kprobes and jprobes. We found the following via a jprobe
to offset_li_node():
jprobe: vma=0xc000000006dc2d78, pol->policy=0x3, pol->v.nodes=0xff, off=0x0
jprobe: vma=0xc00000000f247e30, pol->policy=0x3, pol->v.nodes=0xff, off=0x1000
jprobe: vma=0xc000000006dbf648, pol->policy=0x3, pol->v.nodes=0xff, off=0x2000
...
jprobe: vma=0xc00000000f298870, pol->policy=0x3, pol->v.nodes=0xff, off=0x17000
jprobe: vma=0xc00000000f298368, pol->policy=0x3, pol->v.nodes=0xff, off=0x18000
So, it's quite clear that the nodemask is set appropriately and so is
the policy. The problem, in fact, is the "offset" being passed into
offset_li_node().
The problem, I think, is from interleave_nid():
off = vma->vm_pgoff;
off += (addr - vma->vm_start) >> shift;
return offset_il_node(pol, vma, off);
For hugetlbfs vma's, since vm_pgoff is in units of small pages, the lower
(HPAGE_SHIFT - PAGE_SHIFT) bits of vma->vm_pgoff and off will always be zero
(12 in this case). Thus, when we get into offset_li_node():
unsigned nnodes = nodes_weight(pol->v.nodes);
unsigned target = (unsigned)off % nnodes;
int c;
int nid = -1;
c = 0;
do {
nid = next_node(nid, pol->v.nodes);
c++;
} while (c <= target);
return nid;
nnodes is 8 (the number of nodes). Our offset (some multiple of 4096) is
always going to be evenly divided by 8. So, our target node is always
node 0! Note, that when we took out a bit in our nodemask, nnodes
changed accordingly and 7 did not evenly divide the offset, and we got
interleaving as expected.
To test my hypothesis (my analysis may be a bit hand-wavy, sorry), I
changed interleave_nid() to shift off right by (HPAGE_SHIFT -
PAGE_SHIFT) only #if CONFIG_HUGETLB_PAGE. This fixes the behavior for
the page-by-page case. But I'm not sure this is an acceptable mainline
change, but I've included my signed-off-but-not-for-inclusion patch.
Note, that when I try this with my testcase that makes each allocation
be 4 hugepages large, I get 4 hugepages on node 0, then 4 on node 4,
then 4 on node 0, and so on. I believe this is because the offset ends
up being the same for all of the 4 hugepages in each set, so they go to
the same node
Many thanks to Tim for his help debugging.
---
Once again, not for inclusion!
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
diff -urpN 2.6.18-rc5/mm/mempolicy.c 2.6.18-rc5-dev/mm/mempolicy.c
--- 2.6.18-rc5/mm/mempolicy.c 2006-08-30 22:55:33.000000000 -0700
+++ 2.6.18-rc5-dev/mm/mempolicy.c 2006-08-30 22:56:43.000000000 -0700
@@ -1169,6 +1169,7 @@ static unsigned offset_il_node(struct me
return nid;
}
+#ifndef CONFIG_HUGETLBFS
/* Determine a node number for interleave */
static inline unsigned interleave_nid(struct mempolicy *pol,
struct vm_area_struct *vma, unsigned long addr, int shift)
@@ -1182,8 +1183,22 @@ static inline unsigned interleave_nid(st
} else
return interleave_nodes(pol);
}
+#else
+/* Determine a node number for interleave */
+static inline unsigned interleave_nid(struct mempolicy *pol,
+ struct vm_area_struct *vma, unsigned long addr, int shift)
+{
+ if (vma) {
+ unsigned long off;
+
+ off = vma->vm_pgoff;
+ off += (addr - vma->vm_start) >> shift;
+ off >>= (HPAGE_SHIFT - PAGE_SHIFT);
+ return offset_il_node(pol, vma, off);
+ } else
+ return interleave_nodes(pol);
+}
-#ifdef CONFIG_HUGETLBFS
/* Return a zonelist suitable for a huge page allocation. */
struct zonelist *huge_zonelist(struct vm_area_struct *vma, unsigned long addr)
{
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] powerpc: More via-pmu backlight fixes
From: Benjamin Herrenschmidt @ 2006-08-31 6:42 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linuxppc-dev list
The via-pmu backlight code (introduced in 2.6.18) has various design
issues causing crashes on machines using it like the old Wallstreet
powerbook (Michael, the author, never managed to test on these and I
just got my hand on one of those old beasts).
This fixes them by no longer trying to hijack the backlight device of
the frontmost framebuffer (causing that framebuffer to crash) but having
it's own local bits instead. Might look weird but it's better that way
on those old machines, at least as a last-minute fix for 2.6.18. We
might rework the whole thing later. This patch also changes the way it
gets notified of sleep and wakeup in order to properly shut the
backlight down on sleep and bring it back on wakeup.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
To be applied to 2.6.18 as the current code crashes on some models.
Index: linux-work/drivers/macintosh/via-pmu-backlight.c
===================================================================
--- linux-work.orig/drivers/macintosh/via-pmu-backlight.c 2006-08-17 09:26:20.000000000 +1000
+++ linux-work/drivers/macintosh/via-pmu-backlight.c 2006-08-31 15:49:27.000000000 +1000
@@ -18,17 +18,48 @@
static struct backlight_properties pmu_backlight_data;
static spinlock_t pmu_backlight_lock;
static int sleeping;
+static u8 bl_curve[FB_BACKLIGHT_LEVELS];
-static int pmu_backlight_get_level_brightness(struct fb_info *info,
- int level)
+static void pmu_backlight_init_curve(u8 off, u8 min, u8 max)
+{
+ unsigned int i, flat, count, range = (max - min);
+
+ bl_curve[0] = off;
+
+ for (flat = 1; flat < (FB_BACKLIGHT_LEVELS / 16); ++flat)
+ bl_curve[flat] = min;
+
+ count = FB_BACKLIGHT_LEVELS * 15 / 16;
+ for (i = 0; i < count; ++i)
+ bl_curve[flat + i] = min + (range * (i + 1) / count);
+}
+
+static int pmu_backlight_curve_lookup(int value)
+{
+ int level = (FB_BACKLIGHT_LEVELS - 1);
+ int i, max = 0;
+
+ /* Look for biggest value */
+ for (i = 0; i < FB_BACKLIGHT_LEVELS; i++)
+ max = max((int)bl_curve[i], max);
+
+ /* Look for nearest value */
+ for (i = 0; i < FB_BACKLIGHT_LEVELS; i++) {
+ int diff = abs(bl_curve[i] - value);
+ if (diff < max) {
+ max = diff;
+ level = i;
+ }
+ }
+ return level;
+}
+
+static int pmu_backlight_get_level_brightness(int level)
{
int pmulevel;
/* Get and convert the value */
- mutex_lock(&info->bl_mutex);
- pmulevel = info->bl_curve[level] * FB_BACKLIGHT_MAX / MAX_PMU_LEVEL;
- mutex_unlock(&info->bl_mutex);
-
+ pmulevel = bl_curve[level] * FB_BACKLIGHT_MAX / MAX_PMU_LEVEL;
if (pmulevel < 0)
pmulevel = 0;
else if (pmulevel > MAX_PMU_LEVEL)
@@ -39,7 +70,6 @@ static int pmu_backlight_get_level_brigh
static int pmu_backlight_update_status(struct backlight_device *bd)
{
- struct fb_info *info = class_get_devdata(&bd->class_dev);
struct adb_request req;
unsigned long flags;
int level = bd->props->brightness;
@@ -55,7 +85,7 @@ static int pmu_backlight_update_status(s
level = 0;
if (level > 0) {
- int pmulevel = pmu_backlight_get_level_brightness(info, level);
+ int pmulevel = pmu_backlight_get_level_brightness(level);
pmu_request(&req, NULL, 2, PMU_BACKLIGHT_BRIGHT, pmulevel);
pmu_wait_complete(&req);
@@ -88,35 +118,19 @@ static struct backlight_properties pmu_b
};
#ifdef CONFIG_PM
-static int pmu_backlight_sleep_call(struct pmu_sleep_notifier *self, int when)
+void pmu_backlight_set_sleep(int sleep)
{
unsigned long flags;
spin_lock_irqsave(&pmu_backlight_lock, flags);
-
- switch (when) {
- case PBOOK_SLEEP_REQUEST:
- sleeping = 1;
- break;
- case PBOOK_WAKE:
- sleeping = 0;
- break;
- }
-
+ sleeping = sleep;
spin_unlock_irqrestore(&pmu_backlight_lock, flags);
-
- return PBOOK_SLEEP_OK;
}
-
-static struct pmu_sleep_notifier pmu_backlight_sleep_notif = {
- .notifier_call = pmu_backlight_sleep_call,
-};
-#endif
+#endif /* CONFIG_PM */
void __init pmu_backlight_init()
{
struct backlight_device *bd;
- struct fb_info *info;
char name[10];
int level, autosave;
@@ -131,27 +145,14 @@ void __init pmu_backlight_init()
!machine_is_compatible("PowerBook1,1"))
return;
- /* Actually, this is a hack, but I don't know of a better way
- * to get the first framebuffer device.
- */
- info = registered_fb[0];
- if (!info) {
- printk("pmubl: No framebuffer found\n");
- goto error;
- }
-
- snprintf(name, sizeof(name), "pmubl%d", info->node);
+ snprintf(name, sizeof(name), "pmubl");
- bd = backlight_device_register(name, info, &pmu_backlight_data);
+ bd = backlight_device_register(name, NULL, &pmu_backlight_data);
if (IS_ERR(bd)) {
printk("pmubl: Backlight registration failed\n");
goto error;
}
-
- mutex_lock(&info->bl_mutex);
- info->bl_dev = bd;
- fb_bl_default_curve(info, 0x7F, 0x46, 0x0E);
- mutex_unlock(&info->bl_mutex);
+ pmu_backlight_init_curve(0x7F, 0x46, 0x0E);
level = pmu_backlight_data.max_brightness;
@@ -161,11 +162,9 @@ void __init pmu_backlight_init()
pmu_request(&req, NULL, 2, 0xd9, 0);
pmu_wait_complete(&req);
- mutex_lock(&info->bl_mutex);
- level = pmac_backlight_curve_lookup(info,
+ level = pmu_backlight_curve_lookup(
(req.reply[0] >> 4) *
pmu_backlight_data.max_brightness / 15);
- mutex_unlock(&info->bl_mutex);
}
up(&bd->sem);
@@ -179,10 +178,6 @@ void __init pmu_backlight_init()
pmac_backlight = bd;
mutex_unlock(&pmac_backlight_mutex);
-#ifdef CONFIG_PM
- pmu_register_sleep_notifier(&pmu_backlight_sleep_notif);
-#endif
-
printk("pmubl: Backlight initialized (%s)\n", name);
return;
Index: linux-work/drivers/macintosh/via-pmu.c
===================================================================
--- linux-work.orig/drivers/macintosh/via-pmu.c 2006-08-17 09:26:20.000000000 +1000
+++ linux-work/drivers/macintosh/via-pmu.c 2006-08-31 15:14:33.000000000 +1000
@@ -1995,6 +1995,8 @@ restore_via_state(void)
out_8(&via[IER], IER_SET | SR_INT | CB1_INT);
}
+extern void pmu_backlight_set_sleep(int sleep);
+
static int
pmac_suspend_devices(void)
{
@@ -2032,6 +2034,11 @@ pmac_suspend_devices(void)
return -EBUSY;
}
+#ifdef CONFIG_PMAC_BACKLIGHT
+ /* Tell backlight code not to muck around with the chip anymore */
+ pmu_backlight_set_sleep(1);
+#endif
+
/* Call platform functions marked "on sleep" */
pmac_pfunc_i2c_suspend();
pmac_pfunc_base_suspend();
@@ -2090,6 +2097,11 @@ pmac_wakeup_devices(void)
{
mdelay(100);
+#ifdef CONFIG_PMAC_BACKLIGHT
+ /* Tell backlight code it can use the chip again */
+ pmu_backlight_set_sleep(0);
+#endif
+
/* Power back up system devices (including the PIC) */
device_power_up();
^ permalink raw reply
* [PATCH] powerpc: Fix PowerMac IRQ handling bug
From: Benjamin Herrenschmidt @ 2006-08-31 6:46 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linuxppc-dev list
The port to genirq & the new powerpc interrupt model in 2.6.18
introduced a bug in the legacy PowerMac PIC code (used on older
machines) because of a typo potentially causing hangs due to interrupt
storms. This fixes it, along with a performance issue causing us to do
spurrious retriggers after masking an interrupt.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This is another 2.6.18 regression, please apply to 2.6.18
Index: linux-work/arch/powerpc/platforms/powermac/pic.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/pic.c 2006-08-17 09:26:19.000000000 +1000
+++ linux-work/arch/powerpc/platforms/powermac/pic.c 2006-08-31 16:35:05.000000000 +1000
@@ -87,8 +87,8 @@ static void __pmac_retrigger(unsigned in
static void pmac_mask_and_ack_irq(unsigned int virq)
{
unsigned int src = irq_map[virq].hwirq;
- unsigned long bit = 1UL << (virq & 0x1f);
- int i = virq >> 5;
+ unsigned long bit = 1UL << (src & 0x1f);
+ int i = src >> 5;
unsigned long flags;
spin_lock_irqsave(&pmac_pic_lock, flags);
@@ -175,7 +175,7 @@ static void pmac_mask_irq(unsigned int v
spin_lock_irqsave(&pmac_pic_lock, flags);
__clear_bit(src, ppc_cached_irq_mask);
- __pmac_set_irq_mask(src, 0);
+ __pmac_set_irq_mask(src, 1);
spin_unlock_irqrestore(&pmac_pic_lock, flags);
}
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Andi Kleen @ 2006-08-31 7:47 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, linux-mm, lnxninja, Christoph Lameter
In-Reply-To: <20060831060036.GA18661@us.ibm.com>
On Thursday 31 August 2006 08:00, Nishanth Aravamudan wrote:
> On 30.08.2006 [14:04:40 -0700], Christoph Lameter wrote:
> > > I took out the mlock() call, and I get the same results, FWIW.
> >
> > What zones are available on your box? Any with HIGHMEM?
>
> How do I tell the available zones from userspace? This is ppc64 with
> about 64GB of memory total, it looks like. So, none of the nodes
> (according to /sys/devices/system/node/*/meminfo) have highmem.
The zones are listed at the beginning of dmesg
"On node X total pages ...
DMA zone ...
..."
-Andi
^ permalink raw reply
* Re: PCIe enhanced configuration mechanism support on ppc arch
From: Segher Boessenkool @ 2006-08-31 10:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Milton Miller
In-Reply-To: <1156978993.12526.97.camel@localhost.localdomain>
> An example of platform not using RTAS and that does support extended
> config space is the PCI Express link out of the U4 northbridge on
> PowerMac (though not the other PCIe slots connected to the HT<->PCIe
> tunnel, at least not for now).
>
> It's basically just a matter of having your low level config access
> routines supporting those >=256 offsets. The generic code tests
> that by
> doing a dummy access and checks for an error return.
The U3/U4 HT config access code never returns the error though; it
happily accesses the config space of the next device instead. Got
a patch, will send it later -- it's not a regression, there's no big
hurry for 2.6.18.
Segher
^ permalink raw reply
* Re: could not access the address in linux-System ace driver
From: sudheer @ 2006-08-31 11:42 UTC (permalink / raw)
To: Raja Chidambaram; +Cc: linuxppc-embedded
In-Reply-To: <20060831055304.53524.qmail@web53605.mail.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 7730 bytes --]
Hello Raja,
Thanks for the reply.
Raja Chidambaram wrote:
> Hello Sudheer,
>
> Sorry for the Late reply.since we faced some
> complexity in this kind of system Ace setup we have
> dropped it & moved to different setup.
>
> As of now in your case trace the xilinx code which is
> bascially on adapter.c as for as the xilinix code is
> concerned the hardware initialization code are done
> by xilinux, And only the kernel integration code
> developed by open source developers.So u might to
> track
> this cahnges
>
> As u said your xilinx is connected to EBC make sure
> the power on cycles is perfomed with no errrors.
>
> As for as your base register for xilinux is concerned
> the u-boot handle same as linux but the AMCC 440SPe
> processor have differnet TLB type so please make
> sure u understand TLB for 440SPe.
>
>
>
Can you please send some links if available that tells about the TLBs in
440SPe. I have googled but could not get much information.
Thanks
Sudheer
>
>
>
>
>
> --- sudheer <urwithsudheer@gmail.com> wrote:
>
>
>> Hello All
>>
>> I'm really desperate for some help , I've been
>> struggling with this
>> system since few days.
>>
>> sudheer wrote:
>>
>>> Hello Raja,
>>>
>>> We too are working on customized board with amcc
>>>
>> 440SPe processor ,
>>
>>> xilinx System Ace controller. Compact flash is
>>>
>> connected to system
>>
>>> ace controller.
>>> We use u-boot 1.1.2 as bootloader & linux kernel -
>>>
>> 2.6.16-2.
>>
>>> System ace is connected to amcc440SPE processor
>>>
>> via GPIO and External
>>
>>> Peripheral Bus Controller(EBC).
>>>
>> I am still facing the issue in accessing the address
>> in linux.
>>
>> The physical address given in u-boot init.S
>> tlbentry for 'system ace'
>> is 0xE0000000
>> I am able to access the address in u-boot and
>> everything is fine in u-boot.
>> But in linux , I am able to ioremap the the address
>> 0xE0000000 but the
>> kernel crashes when i try to access the address .
>> physical address=0xe0000000
>> address_after_ioremap = 0xe1000000.
>> I am trying to read with
>> readw(address_after_ioremap)
>> The kernel gives an exception error saying Oops:
>> machine check, sig: 7
>> [#2] .
>> The error dump is as below:
>>
>> Instruction dump:
>> Data machine check in kernel mode.
>> PLB0: BEAR=0x00000000e0000000 ACR= 0xdb000000 BESR=
>> 0x0000000000008000
>> PLB1: BEAR=0xe98d7ad33716ee7e ACR= 0xdb000000 BESR=
>> 0x0000000000000000
>> POB0: BEAR=0x0000000fffaebbcd BESR0=0x00000000
>> BESR1=0x00000000
>> OPB0: BEAR=0x0000000000000000 BSTAT=0x00000000
>> Oops: machine check, sig: 7 [#2]
>> NIP: 00000000 LR: C0002200 CTR: 00000000
>> REGS: c0241f50 TRAP: 0202 Not tainted (2.6.16.2)
>> MSR: 00000000 <> CR: 84CA4124 XER: 00000000
>> TASK = dff6cb70[1] 'swapper' THREAD: c0740000
>> GPR00: 00000000 C0241E40 DFF6CB70 00000001 FFFFFFD0
>> 00000000 C0240000
>> C01F3C0C
>> GPR08: C01F0000 C0002200 00021002 C0001FF4 DFF6CD38
>> 802823E0 1FFB9600
>> 00000000
>> GPR16: 00000001 FFFFFFFF 00000000 007FFF00 1FFB3540
>> 1FF63CE0 1FFCEE78
>> C01C0000
>> GPR24: C01C0000 C01C0000 C01F0000 C01C0000 BFFFFFFF
>> FFFFFFD0 00000000
>> C0241F50
>> NIP [00000000] 0x0
>> LR [C0002200] ret_from_except+0x0/0x18
>> Call Trace:
>> Instruction dump:
>> Data machine check in kernel mode.
>> PLB0: BEAR=0x00000000e0000000 ACR= 0xdb000000 BESR=
>> 0x0000000000008000
>> .........and this dump gets print continously.
>>
>>
>> I have checked with TLB entries in u-boot and linux
>> using BDI:
>>
>> BDI_AMCC440SPe>tlb 0 10
>> IDX TID EPN SIZE VTS RPN USER WIMGE
>> USRSVC
>> 0 : 00 ff000000 16MB V0 -> 4_ff000000 U:0000 WI-G-
>> XWRXWR
>> 1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G-
>> XWRXWR
>> 2 : 00 10000000 256MB V0 -> 0_10000000 U:0000 -I-G-
>> XWRXWR
>> 3 : 00 20000000 256MB V0 -> 0_20000000 U:0000 -I-G-
>> XWRXWR
>> 4 : 00 30000000 256MB V0 -> 0_30000000 U:0000 -I-G-
>> XWRXWR
>> 5 : 00 90000000 256KB V0 -> 4_00000000 U:0000 -I---
>> XWRXWR
>> 6 : 00 e0000000 1KB V0 -> 4_e0000000 U:0000 -I-G-
>> -WR-WR
>> 7 : 00 a0000000 4KB V0 -> 4_f0000000 U:0000 -I-G-
>> -WR-WR
>> 8 : 00 d0000000 256MB V0 -> c_00000000 U:0000 -I-G-
>> -WR-WR
>> 9 : 00 80000000 256MB V0 -> c_10000000 U:0000 -I-G-
>> -WR-WR
>> 10 : 00 01080000 1KB -0 -> 0_00000000 U:0000 -----
>> ------
>> BDI_AMCC440SPe>
>>
>> In Linux the tlb entries are as below.......
>>
>> BDI_AMCC440SPe>tlb 0 63
>> IDX TID EPN SIZE VTS RPN USER WIMGE
>> USRSVC
>> 0 : 0e 0ff1a000 4KB V0 -> 0_007ce000 U:0000 --MG-
>> --R--R
>> 1 : 0e 0fe94000 4KB V0 -> 0_1ff96000 U:0000 ---G-
>> X-RX-R
>> 2 : 0e 30017000 4KB V0 -> 0_007cd000 U:0000 --MG-
>> --R-WR
>> 3 : 0e 10039000 4KB V0 -> 0_1ffb8000 U:0000 ---G-
>> X-RX-R
>> 4 : 0e 30009000 4KB V0 -> 0_00758000 U:0000 ---G-
>> X-RX-R
>> 5 : 0e 30010000 4KB V0 -> 0_0078b000 U:0000 ---G-
>> X-RX-R
>> 6 : 0e 00000000 1KB -0 -> 0_1f4e2000 U:0000 ---G-
>> --R--R
>> 7 : 0e 0fe3e000 4KB V0 -> 0_1f4e2000 U:0000 ---G-
>> X-RX-R
>> 8 : 0e 0ff1c000 4KB V0 -> 0_007ed000 U:0000 --MG-
>> XWRXWR
>> 9 : 0e 0ff1e000 4KB V0 -> 0_007ee000 U:0000 --MG-
>> -WR-WR
>> 10 : 0e 0ff1f000 4KB V0 -> 0_007ea000 U:0000 --MG-
>> XWRXWR
>> 11 : 0e 0fe39000 4KB V0 -> 0_1ff8e000 U:0000 ---G-
>> X-RX-R
>> 12 : 0e 0ff21000 4KB V0 -> 0_007a8000 U:0000 --MG-
>> --R-WR
>> 13 : 0e 0fe47000 4KB V0 -> 0_1ffa9000 U:0000 ---G-
>> X-RX-R
>> 14 : 0e 0fe46000 4KB V0 -> 0_1ffb2000 U:0000 ---G-
>> X-RX-R
>> 15 : 0e 30019000 4KB V0 -> 0_007c5000 U:0000 --MG-
>> -WR-WR
>> 16 : 0e 0fe45000 4KB V0 -> 0_1ffa8000 U:0000 ---G-
>> X-RX-R
>> 17 : 00 fdfff000 4KB V0 -> 4_f0000000 U:0000 -IMG-
>> ----WR
>> 18 : 0e 0fe9a000 4KB V0 -> 0_1ff98000 U:0000 ---G-
>> X-RX-R
>> 19 : 0e 10067000 4KB V0 -> 0_0078e000 U:0000 --MG-
>> -WR-WR
>> 20 : 0e 00000000 4KB -0 -> 0_1f4e5000 U:0000 ---G-
>> --R--R
>> 21 : 0e 10030000 4KB V0 -> 0_1f4e5000 U:0000 ---G-
>> X-RX-R
>> 22 : 0e 10063000 4KB V0 -> 0_007b7000 U:0000 --MG-
>> -WR-WR
>> 23 : 0e 0fe4c000 4KB V0 -> 0_1ff9b000 U:0000 ---G-
>> X-RX-R
>> 24 : 0e 1007f000 4KB V0 -> 0_007e0000 U:0000 --MG-
>> -WR-WR
>> 25 : 0e 0ff1d000 4KB V0 -> 0_007c6000 U:0000 --MG-
>> --R-WR
>> 26 : 0e 0fe4e000 4KB V0 -> 0_1ffa1000 U:0000 ---G-
>> X-RX-R
>> 27 : 0e 0fe0f000 4KB V0 -> 0_0077e000 U:0000 ---G-
>> X-RX-R
>> 28 : 0e 0fe52000 4KB V0 -> 0_0077f000 U:0000 ---G-
>> X-RX-R
>> 29 : 0e 0fe53000 4KB V0 -> 0_1ff80000 U:0000 ---G-
>> X-RX-R
>> 30 : 0e 0fef9000 4KB V0 -> 0_1ff81000 U:0000 ---G-
>> --R--R
>> 31 : 0e 0fe3b000 4KB V0 -> 0_1ffa7000 U:0000 ---G-
>> X-RX-R
>> 32 : 0e 7f901000 4KB V0 -> 0_007db000 U:0000 --MG-
>> -WR-WR
>> 33 : 0e 10027000 4KB V0 -> 0_1ffd0000 U:0000 ---G-
>> X-RX-R
>> 34 : 0e 1003a000 4KB V0 -> 0_1ffb6000 U:0000 ---G-
>> X-RX-R
>> 35 : 0e 0fe51000 4KB V0 -> 0_00775000 U:0000 ---G-
>> X-RX-R
>> 36 : 0e 1003b000 4KB V0 -> 0_1ffb7000 U:0000 ---G-
>> X-RX-R
>> 37 : 0e 1002a000 4KB V0 -> 0_1ffcf000 U:0000 ---G-
>> X-RX-R
>> 38 : 0e 10066000 4KB V0 -> 0_007de000 U:0000 --MG-
>> -WR-WR
>> 39 : 0e 1002b000 4KB V0 -> 0_1ffd3000 U:0000 ---G-
>> X-RX-R
>> 40 : 0e 1002c000 4KB V0 -> 0_1ffd2000 U:0000 ---G-
>> X-RX-R
>> 41 : 0e 1005d000 4KB V0 -> 0_007f4000 U:0000 --MG-
>> XWRXWR
>> 42 : 0e 1002d000 4KB V0 -> 0_1ffc2000 U:0000 ---G-
>> X-RX-R
>> 43 : 0e 10028000 4KB V0 -> 0_1ffc8000 U:0000 ---G-
>> X-RX-R
>> 44 : 0e 10069000 4KB V0 -> 0_0078d000 U:0000 --MG-
>> -WR-WR
>>
>>
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
[-- Attachment #2: Type: text/html, Size: 8443 bytes --]
^ permalink raw reply
* Re: PCIe enhanced configuration mechanism support on ppc arch
From: Benjamin Herrenschmidt @ 2006-08-31 12:02 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Milton Miller
In-Reply-To: <11BC5236-0411-402A-A3F1-0FB5E8059FA0@kernel.crashing.org>
On Thu, 2006-08-31 at 12:11 +0200, Segher Boessenkool wrote:
> > An example of platform not using RTAS and that does support extended
> > config space is the PCI Express link out of the U4 northbridge on
> > PowerMac (though not the other PCIe slots connected to the HT<->PCIe
> > tunnel, at least not for now).
> >
> > It's basically just a matter of having your low level config access
> > routines supporting those >=256 offsets. The generic code tests
> > that by
> > doing a dummy access and checks for an error return.
>
> The U3/U4 HT config access code never returns the error though; it
> happily accesses the config space of the next device instead. Got
> a patch, will send it later -- it's not a regression, there's no big
> hurry for 2.6.18.
Better to have it in if possible though. Thanks
Ben.
^ permalink raw reply
* mvme
From: Loïc Damm @ 2006-08-31 12:25 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
Hello,
I found a page about MVME cards on the web posted by you... I was
trying to fix a problem with a machine running OS9, so I was asking
to myself if you could help me. I would be very happy if you took few
minutes to consider this mail...
So, my problem is about booting a Motorola MVME 162-223 card. I have
changed the battery necessary to back-up the card parameters (and
probably other types...) in NVRAM but now the card is unable to
autoboot and stays in Bug mode. All hardware tests are passed. I have
reinitialized it (with bf and env;d comands) but it is still
impossible to boot. I do not understand because the OS9 system seems
to be stored on a flash memory. The card is unable to find the
localization of Operating System boot file.
I am really sorry to disturb you... but any idea would be useful for
me. Power Pc is not an architecture I am familiar with and now few
people have knowledge about this system.
Sincerely
Loïc
Loïc Damm
Doctorant / Phd Student
Collège de France - LPPA
Equipe Espace
11 place Marcelin Berthelot
75005 Paris
France
Tel +33 1 44 27 13 80
Mob +33 6 7007 1991
Fax +33 1 44 27 13 82
loic.damm@college-de-france.fr
[-- Attachment #2: Type: text/html, Size: 4833 bytes --]
^ permalink raw reply
* watchdog on mpc8260 with embedded linux
From: Wang LP @ 2006-08-31 13:18 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 120 bytes --]
we try to us the hardware watchdog on mpc8260, anyone have the
similar code?our linux os version is 2.6.18.
thank you.
[-- Attachment #2: Type: text/html, Size: 164 bytes --]
^ permalink raw reply
* Men em1 MPC5200 kernel don't start using elinos v4.0
From: Fodjo Yves-Eric @ 2006-08-31 13:38 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]
Hello
In the course of my Thesis I have to Port linux on the board EM01 Rev 01.04.02 of Men using Elinos V4 PPC. My host system is Linux Fedora Core 5. I'm using the "menem1" as board. The problem is that the kernel doesn't start at all. After loading the file "hello.img" througth bootp the system give the following output and hang.
Searching for server (BOOTP) .
My IP 192.168.1.10:ffffff00 Server IP 192.168.1.1 GW IP 192.168.1.1
Loading hello.img...
to 0x02000000 861 kB
Loaded 0x000d74e9 bytes
Detected PPCBOOT header
verifiying image CRC...ok
Uncompressing Multi-File Image ... ok
Moving initrd...ok
passing parameters: devfs=mount rootfstype=tmpfs root=dev/ram rw ip=auto
Starting Linux Kernel.
I have tried several combination of kernel parameters without success.
Here is a part of my ELINOS.sh config file.
# --- Configuration Settings ------------------------------------------
ELINOS_BOARD="menem1"
export ELINOS_BOARD
ELINOS_CPU="ppc"
export ELINOS_CPU
ELINOS_ARCH="60x"
export ELINOS_ARCH
ELINOS_LIBC="glibc-2.3.4"
export ELINOS_LIBC
ELINOS_BOARD_LINUX_ARCH=""
export ELINOS_BOARD_LINUX_ARCH
ELINOS_DOSNAME="hello"
export ELINOS_DOSNAME
ELINOS_BOOT_STRAT="uboot_multi"
export ELINOS_BOOT_STRAT
ELINOS_KERNELPATH="menem1/linux-2.6.12"
export ELINOS_KERNELPATH
MKIMAGE_LOAD_ADDRESS="00000000"
export MKIMAGE_LOAD_ADDRESS
MKIMAGE_ENTRY_ADDRESS="00000000"
export MKIMAGE_ENTRY_ADDRESS
.
.
ELINOS_VERSION="4.0"
Thanks.
---------------------------------
Stay in the know. Pulse on the new Yahoo.com. Check it out.
---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail.
[-- Attachment #2: Type: text/html, Size: 2064 bytes --]
^ permalink raw reply
* Re: Men em1 MPC5200 kernel don't start using elinos v4.0
From: Gerhard Jaeger @ 2006-08-31 14:08 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Fodjo Yves-Eric
In-Reply-To: <20060831133857.67615.qmail@web52605.mail.yahoo.com>
On Thursday 31 August 2006 15:38, Fodjo Yves-Eric wrote:
> Hello
> In the course of my Thesis I have to Port linux on the board EM01 Rev 01.04.02 of Men using Elinos V4 PPC. My host system is Linux Fedora Core 5. I'm using the "menem1" as board. The problem is that the kernel doesn't start at all. After loading the file "hello.img" througth bootp the system give the following output and hang.
>
> Searching for server (BOOTP) .
> My IP 192.168.1.10:ffffff00 Server IP 192.168.1.1 GW IP 192.168.1.1
> Loading hello.img...
> to 0x02000000 861 kB
> Loaded 0x000d74e9 bytes
> Detected PPCBOOT header
> verifiying image CRC...ok
> Uncompressing Multi-File Image ... ok
> Moving initrd...ok
> passing parameters: devfs=mount rootfstype=tmpfs root=dev/ram rw ip=auto
> Starting Linux Kernel.
>
>
> I have tried several combination of kernel parameters without success.
> Here is a part of my ELINOS.sh config file.
Hi,
I guess this is the wrong list for asking disto specific questions ;)
I don't have this board here currently, but one guess is, that you should
add the correct console parameter to the kernelparameter list.
HTH
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ 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