* RE: [PATCH 4/4] Add MPC8349E MDS device tree source filetoarch/powerpc/boot/dts
From: Li Yang-r58472 @ 2006-08-28 6:11 UTC (permalink / raw)
To: Li Yang-r58472, Phillips Kim-R1AAHA, linuxppc-dev
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC5A7@zch01exm20.fsl.freescale.net>
> {snip}
> > +
> > + pci@8500 {
> > + interrupt-map-mask =3D <f800 0 0 7>;
> > + interrupt-map =3D <
> > +
> > + /* IDSEL 0x11 */
> > + 8800 0 0 1 700 14 0
> > + 8800 0 0 2 700 15 0
> > + 8800 0 0 3 700 16 0
> > + 8800 0 0 4 700 17 0
>=20
> If we are changing sense definition in IPIC, we should change the
> mapping to lines like below:
> 8800 0 0 1 700 14 2
Sorry, should be 8 for level low.
^ permalink raw reply
* RE: Cache coherency question
From: Li Yang-r58472 @ 2006-08-28 6:57 UTC (permalink / raw)
To: Liu Dave-r63238, Martin, Tim, ppc
In-Reply-To: <995B09A8299C2C44B59866F6391D263511B8CA@zch01exm21.fsl.freescale.net>
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf Of
> Liu Dave-r63238
> Sent: Monday, August 28, 2006 11:18 AM
> To: Martin, Tim; ppc
> Subject: RE: Cache coherency question
>=20
> > Ah. This must be the problem. I have a few PCI devices, and
> > on one of them it looked like snooping was working. I just
> > assumed the other device was setup correctly.
>=20
> Why one is looked like snooping was working, and the other device
> not working?
>=20
> > > Also, you can define the CONFIG_NOT_COHERENT_CACHE, then you are
> > > assuming The system has not hardware coherency. You need use the
> > > software to keep the cache coherency.
> > >
> >
> > I tried this, and got compiler errors.
Which arch are you using? powerpc or ppc? CONFIG_NOT_COHERENT_CACHE
doesn't seem to be ported to powerpc arch completely.
>=20
> What is the file got compiler errors? I notice that the
> /ev64360_defconfig
> Did define CONFIG_NOT_COHERENT_CACHE.
>=20
>=20
> > I added some inline assembly dcbi/dcbf (invalidate/flush)
> > instructions to the particular code in question, and the
> > problems went away. So definitely a cache problem. As I
> > said above, defining CONFIG_NOT_COHERENT_CACHE causes
> > compiler errors, so I'm going to look into this more. I
> > suppose whatever file implements the
> > include/linux/dma-mapping.h stuff isn't BSP specific, so its
> > probably just not being compiled in? Will look into it.
>=20
> Somebody said from maillist. The bridge MV64360 seems
> having some issue about cache coherent. I don't know if it is really?
Looking from source code, there is such problem for MV64360. It's
likely that MV54360 has the same problem.
^ permalink raw reply
* RE: Cache coherency question
From: Liu Dave-r63238 @ 2006-08-28 7:00 UTC (permalink / raw)
To: Li Yang-r58472, Martin, Tim, ppc
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC5FF@zch01exm20.fsl.freescale.net>
<snip>
> Looking from source code, there is such problem for MV64360. =20
> It's likely that MV54360 has the same problem.
What is the MV54360?=20
-Dave
^ permalink raw reply
* RE: Cache coherency question
From: Li Yang-r58472 @ 2006-08-28 7:08 UTC (permalink / raw)
To: Liu Dave-r63238, Martin, Tim, ppc
In-Reply-To: <995B09A8299C2C44B59866F6391D263511B930@zch01exm21.fsl.freescale.net>
> -----Original Message-----
> From: Liu Dave-r63238
> Sent: Monday, August 28, 2006 3:00 PM
> To: Li Yang-r58472; 'Martin, Tim'; 'ppc'
> Subject: RE: Cache coherency question
>=20
> <snip>
> > Looking from source code, there is such problem for MV64360.
> > It's likely that MV54360 has the same problem.
>=20
> What is the MV54360?
>From document at
http://www.motorola.com/mot/doc/5/5503_MotDoc.pdf#search=3D%22MV54360%22
The board uses MV54360.
I don't know if it is a typo or new variant though.
>=20
> -Dave
^ permalink raw reply
* Re: powerpc virq: new routine virq_to_hw
From: Segher Boessenkool @ 2006-08-28 7:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1156728139.8433.413.camel@localhost.localdomain>
> I'd much prefer:
>
> static inline irq_hw_number_t virq_to_hw (unsigned int virq)
> {
> return irq_map[virq].hwirq;
> }
>
> I've grown to dislike the CR between the return type and the function
> name (I used to do that too) and it seems that this opinion is
> shared by
> Linus (there was an old thread on lkml about it).
And while we're at it: no space before parenthesis in a function
declaration/definition.
Segher
^ permalink raw reply
* [QUESTION] Enable coherency for all pages on 83xx to fix PCI data corruption
From: Liu Dave-r63238 @ 2006-08-28 7:49 UTC (permalink / raw)
To: linuxppc-dev
All,
I want to know which PCI errata is solved by this patch
and if this patch did test on real hardware.
I know this patch turn on the 'M' bit -memory coherency.
But I don't believe this can solved the "PCI read multi-line"
errata.
-DAve
http://ozlabs.org/pipermail/linuxppc-dev/2006-February/021267.html
On the 83xx platform to ensure the PCI inbound memory is handled
properly we
have to turn on coherency for all pages in the MMU. Otherwise we see
corruption if inbound "prefetching/streaming" is enabled on the PCI
controller.
Signed-off-by: Randy Vinson <rvinson at mvista.com>
Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---
(For 2.6.16 if we can get it in)
commit 4b2f4b1585f15d1c30cd2eda6d5f9a2ca7dcf998
tree 7aebf508d10127831cf92fb7ce919230924ad85d
parent 7cfb7344aae902edfd5d51dd5f734cbf2585649c
author Kumar Gala <galak at kernel.crashing.org> Wed, 22 Feb 2006
09:53:34 -0600
committer Kumar Gala <galak at kernel.crashing.org> Wed, 22 Feb 2006
09:53:34 -0600
include/asm-powerpc/cputable.h | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/asm-powerpc/cputable.h
b/include/asm-powerpc/cputable.h
index 6421054..90d005b 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -159,9 +159,11 @@ extern void do_cpu_ftr_fixups(unsigned l
#endif
=20
/* We need to mark all pages as being coherent if we're SMP or we
- * have a 74[45]x and an MPC107 host bridge.
+ * have a 74[45]x and an MPC107 host bridge. Also 83xx requires
+ * it for PCI "streaming/prefetch" to work properly.
*/
-#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE)
+#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE) \
+ || defined(CONFIG_PPC_83xx)
#define CPU_FTR_COMMON CPU_FTR_NEED_COHERENT
#else
#define CPU_FTR_COMMON 0
@@ -277,7 +279,8 @@ enum {
CPU_FTRS_G2_LE =3D CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE
|
CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP |
CPU_FTR_HAS_HIGH_BATS,
CPU_FTRS_E300 =3D CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE
|
- CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP |
CPU_FTR_HAS_HIGH_BATS,
+ CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP |
CPU_FTR_HAS_HIGH_BATS |
+ CPU_FTR_COMMON,
CPU_FTRS_CLASSIC32 =3D CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE,
CPU_FTRS_POWER3_32 =3D CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
^ permalink raw reply related
* Re: Cache coherency question
From: Gerhard Jaeger @ 2006-08-28 8:26 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC602@zch01exm20.fsl.freescale.net>
On Monday 28 August 2006 09:08, Li Yang-r58472 wrote:
>
> > -----Original Message-----
> > From: Liu Dave-r63238
> > Sent: Monday, August 28, 2006 3:00 PM
> > To: Li Yang-r58472; 'Martin, Tim'; 'ppc'
> > Subject: RE: Cache coherency question
> >
> > <snip>
> > > Looking from source code, there is such problem for MV64360.
> > > It's likely that MV54360 has the same problem.
> >
> > What is the MV54360?
>
> From document at
> http://www.motorola.com/mot/doc/5/5503_MotDoc.pdf#search=%22MV54360%22
> The board uses MV54360.
>
> I don't know if it is a typo or new variant though.
It's definitely a typo. In the block diagramm you'll see Discovery II
as system bridge and this one is the Marvel MV64360 (at least on the MVME6100).
-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
* [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: Russell King @ 2006-08-28 8:52 UTC (permalink / raw)
To: linux-ia64, linux-mips, linuxppc-embedded, paulkf, takata,
linux-kernel
asm/serial.h is supposed to contain the definitions for the architecture
specific 8250 ports for the 8250 driver. It may also define BASE_BAUD,
but this is the base baud for the architecture specific ports _only_.
Therefore, nothing other than the 8250 driver should be including this
header file. In order to move towards this goal, here is a patch which
removes some of the more obvious incorrect includes of the file.
MIPS and PPC has rather a lot of stuff in asm/serial.h, some of it looks
related to non-8250 ports. Hence, it's not trivial to conclude that
these includes are indeed unnecessary, so can mips and ppc people please
test this patch carefully.
Thanks.
diff --git a/arch/frv/kernel/setup.c b/arch/frv/kernel/setup.c
--- a/arch/frv/kernel/setup.c
+++ b/arch/frv/kernel/setup.c
@@ -31,7 +31,6 @@
#include <linux/serial_reg.h>
#include <asm/setup.h>
-#include <asm/serial.h>
#include <asm/irq.h>
#include <asm/sections.h>
#include <asm/pgalloc.h>
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -54,7 +54,6 @@
#include <asm/processor.h>
#include <asm/sal.h>
#include <asm/sections.h>
-#include <asm/serial.h>
#include <asm/setup.h>
#include <asm/smp.h>
#include <asm/system.h>
diff --git a/arch/mips/cobalt/setup.c b/arch/mips/cobalt/setup.c
--- a/arch/mips/cobalt/setup.c
+++ b/arch/mips/cobalt/setup.c
@@ -23,7 +23,6 @@
#include <asm/processor.h>
#include <asm/reboot.h>
#include <asm/gt64120.h>
-#include <asm/serial.h>
#include <asm/mach-cobalt/cobalt.h>
diff --git a/arch/mips/lasat/setup.c b/arch/mips/lasat/setup.c
--- a/arch/mips/lasat/setup.c
+++ b/arch/mips/lasat/setup.c
@@ -34,7 +34,6 @@
#include <asm/cpu.h>
#include <asm/bootinfo.h>
#include <asm/irq.h>
-#include <asm/serial.h>
#include <asm/lasat/lasat.h>
#include <asm/lasat/serial.h>
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -51,7 +51,6 @@
#include <asm/system.h>
#include <asm/rtas.h>
#include <asm/iommu.h>
-#include <asm/serial.h>
#include <asm/cache.h>
#include <asm/page.h>
#include <asm/mmu.h>
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -38,7 +38,6 @@
#include <asm/nvram.h>
#include <asm/xmon.h>
#include <asm/time.h>
-#include <asm/serial.h>
#include <asm/udbg.h>
#include "setup.h"
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -51,7 +51,6 @@
#include <asm/system.h>
#include <asm/rtas.h>
#include <asm/iommu.h>
-#include <asm/serial.h>
#include <asm/cache.h>
#include <asm/page.h>
#include <asm/mmu.h>
diff --git a/drivers/char/pcmcia/synclink_cs.c b/drivers/char/pcmcia/synclink_cs.c
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -57,7 +57,6 @@
#include <linux/netdevice.h>
#include <linux/vmalloc.h>
#include <linux/init.h>
-#include <asm/serial.h>
#include <linux/delay.h>
#include <linux/ioctl.h>
diff --git a/drivers/char/synclink.c b/drivers/char/synclink.c
--- a/drivers/char/synclink.c
+++ b/drivers/char/synclink.c
@@ -87,7 +87,6 @@
#include <linux/vmalloc.h>
#include <linux/init.h>
-#include <asm/serial.h>
#include <linux/delay.h>
#include <linux/ioctl.h>
diff --git a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
--- a/drivers/serial/m32r_sio.c
+++ b/drivers/serial/m32r_sio.c
@@ -76,17 +76,16 @@
*/
#define is_real_interrupt(irq) ((irq) != 0)
-#include <asm/serial.h>
+#define BASE_BAUD 115200
/* Standard COM flags */
#define STD_COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST)
/*
* SERIAL_PORT_DFNS tells us about built-in ports that have no
* standard enumeration mechanism. Platforms that can find all
* serial ports via mechanisms like ACPI or PCI need not supply it.
*/
-#undef SERIAL_PORT_DFNS
#if defined(CONFIG_PLAT_USRV)
#define SERIAL_PORT_DFNS \
@@ -109,7 +108,7 @@
#endif /* !CONFIG_PLAT_USRV */
static struct old_serial_port old_serial_port[] = {
- SERIAL_PORT_DFNS /* defined in asm/serial.h */
+ SERIAL_PORT_DFNS
};
#define UART_NR ARRAY_SIZE(old_serial_port)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* NON PCI IDE Driver for 2.6
From: Akhilesh Soni @ 2006-08-28 12:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 337 bytes --]
Hi,
I've recently ported my powerpc 405 Redwood6 platform to 2.6 kernel. Earlier in 2.4 I was using IBM driver (drivers/ide/ocp_stbxxxxx.c) for IDE disk interface. I've searched but I coundn't find the same for 2.6 kernel. Is the same available for 2.6 or any other similar driver would work. Please advice.
Regards,
Akhilesh
[-- Attachment #2: Type: text/html, Size: 928 bytes --]
^ permalink raw reply
* Re: [QUESTION] Enable coherency for all pages on 83xx to fix PCI data corruption
From: Kumar Gala @ 2006-08-28 13:49 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: linuxppc-dev
In-Reply-To: <995B09A8299C2C44B59866F6391D263511B945@zch01exm21.fsl.freescale.net>
This was to address PCI5 if I remember correctly.
- kumar
On Aug 28, 2006, at 2:49 AM, Liu Dave-r63238 wrote:
> All,
>
> I want to know which PCI errata is solved by this patch
> and if this patch did test on real hardware.
>
> I know this patch turn on the 'M' bit -memory coherency.
> But I don't believe this can solved the "PCI read multi-line"
> errata.
>
> -DAve
>
> http://ozlabs.org/pipermail/linuxppc-dev/2006-February/021267.html
>
> On the 83xx platform to ensure the PCI inbound memory is handled
> properly we
> have to turn on coherency for all pages in the MMU. Otherwise we see
> corruption if inbound "prefetching/streaming" is enabled on the PCI
> controller.
>
> Signed-off-by: Randy Vinson <rvinson at mvista.com>
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>
> ---
>
> (For 2.6.16 if we can get it in)
>
> commit 4b2f4b1585f15d1c30cd2eda6d5f9a2ca7dcf998
> tree 7aebf508d10127831cf92fb7ce919230924ad85d
> parent 7cfb7344aae902edfd5d51dd5f734cbf2585649c
> author Kumar Gala <galak at kernel.crashing.org> Wed, 22 Feb 2006
> 09:53:34 -0600
> committer Kumar Gala <galak at kernel.crashing.org> Wed, 22 Feb 2006
> 09:53:34 -0600
>
> include/asm-powerpc/cputable.h | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/include/asm-powerpc/cputable.h
> b/include/asm-powerpc/cputable.h
> index 6421054..90d005b 100644
> --- a/include/asm-powerpc/cputable.h
> +++ b/include/asm-powerpc/cputable.h
> @@ -159,9 +159,11 @@ extern void do_cpu_ftr_fixups(unsigned l
> #endif
>
> /* We need to mark all pages as being coherent if we're SMP or we
> - * have a 74[45]x and an MPC107 host bridge.
> + * have a 74[45]x and an MPC107 host bridge. Also 83xx requires
> + * it for PCI "streaming/prefetch" to work properly.
> */
> -#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE)
> +#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE) \
> + || defined(CONFIG_PPC_83xx)
> #define CPU_FTR_COMMON CPU_FTR_NEED_COHERENT
> #else
> #define CPU_FTR_COMMON 0
> @@ -277,7 +279,8 @@ enum {
> CPU_FTRS_G2_LE = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE
> |
> CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP |
> CPU_FTR_HAS_HIGH_BATS,
> CPU_FTRS_E300 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE
> |
> - CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP |
> CPU_FTR_HAS_HIGH_BATS,
> + CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP |
> CPU_FTR_HAS_HIGH_BATS |
> + CPU_FTR_COMMON,
> CPU_FTRS_CLASSIC32 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
> CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE,
> CPU_FTRS_POWER3_32 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
^ permalink raw reply
* uart_cpm scc Rx problem after second open of the device
From: Alexandros Kostopoulos @ 2006-08-28 14:04 UTC (permalink / raw)
To: linuxppc-dev
I experienced a problem with the cpm_uart scc driver (kernel version =
2.6.13) while running the driver for a serial port NOT configured as a =
console.
The problem is as follows:
The first time the device (/dev/ttyCPM0) is opened, everything works ok.=
=
The second time, however, the device is opened, receive does not work. T=
he =
device can only transmit, but doesn't receive anything.
Well, by looking into the code, I found out that the ENR (Receiver enabl=
e) =
bit of the GSMR-L register is only set in cpm_uart_init_scc and NOT in
cpm_uart_startup, as I think it should. Then, the bit is cleared on =
cpm_uart_shutdown. Thus, the first time the device is opened, the bit is=
=
set (and so, the device normally receives data), but the second time the=
=
device is opened, the bit is NOT set and the device cannot receive =
anything from the serial port.
The diff of my code against the original 2.6.13 code follows (although i=
=
saw that the 2.6.17 code is exactly the same as far as the ENR bit is
concerned):
Index: cpm_uart_core.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- cpm_uart_core.c (revision 79)
+++ cpm_uart_core.c (revision 105)
@@ -393,6 +393,7 @@
pinfo->smcp->smc_smcm |=3D SMCM_RX;
pinfo->smcp->smc_smcmr |=3D SMCMR_REN;
} else {
+ pinfo->sccp->scc_gsmrl |=3D (SCC_GSMRL_ENR);
pinfo->sccp->scc_sccm |=3D UART_SCCM_RX;
}
Am I missing something here?
Thanks for any comments,
Alex.
^ permalink raw reply
* Re: uart_cpm scc Rx problem after second open of the device
From: Vitaly Bordug @ 2006-08-28 14:50 UTC (permalink / raw)
To: Alexandros Kostopoulos; +Cc: linuxppc-dev
In-Reply-To: <op.tezypejhnhx3hy@draco>
On Mon, 28 Aug 2006 17:04:16 +0300
"Alexandros Kostopoulos" <akostop@inaccessnetworks.com> wrote:
> I experienced a problem with the cpm_uart scc driver (kernel version
> 2.6.13) while running the driver for a serial port NOT configured as a
> console.
> The problem is as follows:
> The first time the device (/dev/ttyCPM0) is opened, everything works ok.
> The second time, however, the device is opened, receive does not work. The
> device can only transmit, but doesn't receive anything.
>
I'm recalling to fix it a while ago (later than .14 though). There were not just the line below,
but you cant find the respective stuff on the line (linuxppc-embedded) archive/ kernel git.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: powerpc virq: new routine virq_to_hw
From: Geoff Levand @ 2006-08-28 15:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1156728139.8433.413.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> I'd much prefer:
>
> static inline irq_hw_number_t virq_to_hw (unsigned int virq)
> {
> return irq_map[virq].hwirq;
> }
Here is an updated version.
-Geoff
This adds an accessor routine virq_to_hw() to the
virq routines which hides the implementation details
of the virq to hwirq map.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Index: cell--common--4/include/asm-powerpc/irq.h
===================================================================
--- cell--common--4.orig/include/asm-powerpc/irq.h
+++ cell--common--4/include/asm-powerpc/irq.h
@@ -136,6 +136,10 @@
extern struct irq_map_entry irq_map[NR_IRQS];
+static inline irq_hw_number_t virq_to_hw(unsigned int virq)
+{
+ return irq_map[virq].hwirq;
+}
/**
* irq_alloc_host - Allocate a new irq_host data structure
^ permalink raw reply
* RE: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: Luck, Tony @ 2006-08-28 16:28 UTC (permalink / raw)
To: Russell King, linux-ia64, linux-mips, linuxppc-embedded, paulkf,
takata, linux-kernel
> diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
Acked-by: Tony Luck <tony.luck@intel.com>
[IA-64 part only ... I didn't look at the rest]
-Tony
^ permalink raw reply
* copy_4K_page() doesn't use dcbtst?
From: Hollis Blanchard @ 2006-08-28 17:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, xen-ppc-devel
Hi Paul, some Xen people were just noticing that copy_4K_page
(arch/powerpc/lib/copypage_64.S) doesn't use the dcbtst instruction. Why
doesn't it help there?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: Willschm @ 2006-08-28 18:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, arnd, segher
In-Reply-To: <17645.18647.720814.903612@cargo.ozlabs.ibm.com>
On Thu, 2006-24-08 at 16:36 +1000, Paul Mackerras wrote:
> Will Schmidt writes:
>
> I just did a patch to fix the existing masks. Could you do a new
> version of this patch that doesn't include the unrelated mask fixes
> please? Also it would be really nice if you could figure out a way to
> avoid doing the unnecessary 64-bit logical operations on 32-bit
> machines - i.e. using an unsigned long for tmp, but then the constants
> become problematic. Maybe you need something like
>
> #define LCONST(x) ((unsigned long)(x##ULL))
Ok, how about this..
In an attempt to make it easier for a power5 optimized app to run on a
power4 or a 970 or random earlier machine, this provides emulation of
the popcntb instruction.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
---
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 2105767..f85a3af 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -588,6 +588,9 @@ #define INST_LSWX 0x7c00042a
#define INST_STSWI 0x7c0005aa
#define INST_STSWX 0x7c00052a
+#define INST_POPCNTB 0x7c0000f4
+#define INST_POPCNTB_MASK 0xfc0007fe
+
static int emulate_string_inst(struct pt_regs *regs, u32 instword)
{
u8 rT = (instword >> 21) & 0x1f;
@@ -656,6 +659,25 @@ static int emulate_string_inst(struct pt
return 0;
}
+#define LCONST(x) ((unsigned long)(x##ULL))
+
+static int emulate_popcntb_inst(struct pt_regs *regs, u32 instword)
+{
+ u32 ra,rs;
+ u64 tmp;
+
+ ra = (instword >> 16) & 0x1f;
+ rs = (instword >> 21) & 0x1f;
+
+ tmp = regs->gpr[rs];
+ tmp = tmp - ((tmp >> 1) & LCONST(0x5555555555555555));
+ tmp = (tmp & LCONST(0x3333333333333333)) + ((tmp >> 2) & LCONST(0x3333333333333333));
+ tmp = (tmp + (tmp >> 4)) & LCONST(0x0f0f0f0f0f0f0f0f);
+ regs->gpr[ra] = tmp;
+
+ return 0;
+}
+
static int emulate_instruction(struct pt_regs *regs)
{
u32 instword;
@@ -693,6 +715,11 @@ static int emulate_instruction(struct pt
if ((instword & INST_STRING_GEN_MASK) == INST_STRING)
return emulate_string_inst(regs, instword);
+ /* Emulate the popcntb (Population Count Bytes) instruction. */
+ if ((instword & INST_POPCNTB_MASK) == INST_POPCNTB) {
+ return emulate_popcntb_inst(regs, instword);
+ }
+
return -EINVAL;
}
^ permalink raw reply related
* Help for bdm4gdb project
From: wei.li4 @ 2006-08-28 18:39 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
Does any one know bdm4gdb project that dosen't exist in
sourceforge.net? I have hardware wiggler and software debugger, but I
need instructions in more details to use it, thanks.
Wei
^ permalink raw reply
* Re: Help for bdm4gdb project
From: Wolfgang Denk @ 2006-08-28 19:50 UTC (permalink / raw)
To: wei.li4; +Cc: linuxppc-embedded
In-Reply-To: <20060828143907.2i3pdjcih44g8okg@webmail.mcgill.ca>
In message <20060828143907.2i3pdjcih44g8okg@webmail.mcgill.ca> you wrote:
>
> Does any one know bdm4gdb project that dosen't exist in
> sourceforge.net? I have hardware wiggler and software debugger, but I
> need instructions in more details to use it, thanks.
See http://www.vas-gmbh.de/software/mpcbdm/
[Don't worry about the name.]
Also, there's bdm4gdb-users@lists.sourceforge.net mailing list. But
don't expect too much - it is LOW traffic, the last posting I
received is more than 6 months old.
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
Systems programmers are the high priests of a low cult.
-- R.S. Barton
^ permalink raw reply
* Converting to new IRQ code
From: Rune Torgersen @ 2006-08-28 19:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi.
Can anybody help me convert the following IRQ demux code to the new IRQ
setup?
I tried just changing irq_desc[irq].handler to irq_desc_[irq].chip, but
then it dumps in _do_IRQ()
This is on a MPC8280 with an ecternal (in FPGA) PCI IRQ mux
static volatile unsigned short * pci_status_reg;
static volatile unsigned short * pci_mask_reg;
static inline int
innsys_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char
pin)
{
//struct pci_controller *hose =3D pci_bus_to_hose(dev->bus->number);
//int temp;
if (!dev->bus->number) // PCI bus 0
{
static char pci_irq_table[][4] =3D
/*
* PCI IDSEL/INTPIN->INTLINE
* A B C D
*/
{
{ PIRQ0, PIRQ0, PIRQ0, PIRQ0 }, /* IDSEL 16 -
CPU2 */
{ PIRQ5, PIRQ5, PIRQ5, PIRQ5 }, /* IDSEL 17 -
IDE controller */
{ PIRQ1, PIRQ2, PIRQ3, PIRQ4 }, /* IDSEL 18 -
Bridge */
};
const long min_idsel =3D 0x10, max_idsel =3D 0x12, irqs_per_slot
=3D 4;
//temp =3D PCI_IRQ_TABLE_LOOKUP;
//printk("<1>0: PCI map IRQ for bus %d, device %d; IDsel =3D %d,
pin %d, irq =3D %d\n",
// dev->bus->number, dev->bus->device, idsel, pin, temp);
return PCI_IRQ_TABLE_LOOKUP;
//return temp;
}
else // PCI bus 1
{
static char pci_irq_table[][4] =3D
/*
* PCI IDSEL/INTPIN->INTLINE
* A B C D
*/
{
{ PIRQ1, PIRQ2, PIRQ3, PIRQ4 }, /* IDSEL 16 -
DSP 0 */
{ PIRQ2, PIRQ2, PIRQ2, PIRQ2 }, /* IDSEL 17 -
DSP 1 */
{ PIRQ3, PIRQ3, PIRQ3, PIRQ3 }, /* IDSEL 18 -
DSP 2 */
{ PIRQ4, PIRQ4, PIRQ4, PIRQ4 }, /* IDSEL 19 -
DSP 2 */
};
const long min_idsel =3D 18, max_idsel =3D 18, irqs_per_slot =3D
4;
return PCI_IRQ_TABLE_LOOKUP; =20
//temp =3D PCI_IRQ_TABLE_LOOKUP;
//printk("<1>1: PCI map IRQ for bus %d, device %d; IDsel =3D %d,
pin %d, irq =3D %d\n",
// dev->bus->number, dev->bus->device, idsel, pin, temp);
//return PCI_IRQ_TABLE_LOOKUP;
//return temp;
}
}
static void
innsys_mask_irq(unsigned int irq)
{
int bit =3D irq - PCI_INT_OFFSET;
// 0 is masked, 1 is enabled
//*(volatile unsigned short *) PCI_INT_MASK_REG &=3D ~(1 << bit);
*pci_mask_reg &=3D ~(1 << bit);
return;
}
static void
innsys_unmask_irq(unsigned int irq)
{
int bit =3D irq - PCI_INT_OFFSET;
//*(volatile unsigned short *) PCI_INT_MASK_REG |=3D (1 << bit);
*pci_mask_reg |=3D (1 << bit);
return;
}
static void
innsys_mask_and_ack(unsigned int irq)
{
int bit =3D irq - PCI_INT_OFFSET;
//*(volatile unsigned short *) PCI_INT_MASK_REG &=3D ~(1 << bit);
*pci_mask_reg &=3D ~(1 << bit);
//__asm("sync");
return;
}
static void
innsys_end_irq(unsigned int irq)
{
int bit =3D irq - PCI_INT_OFFSET;
//*(volatile unsigned short *) PCI_INT_MASK_REG |=3D (1 << bit);
*pci_mask_reg |=3D (1 << bit);
return;
}
struct hw_interrupt_type innsys_ic =3D {
" AP2PCI ",
NULL,
NULL,
innsys_unmask_irq,
innsys_mask_irq,
innsys_mask_and_ack,
innsys_end_irq,
0
};
static irqreturn_t
pci_irq_demux(int irq, void *dev_id, struct pt_regs *regs)
{
unsigned short stat, mask, pend;
int bit;
for(;;) {
//stat =3D *(volatile unsigned short *) PCI_INT_STAT_REG;
//mask =3D *(volatile unsigned short *) PCI_INT_MASK_REG;
stat =3D *pci_status_reg;
mask =3D *pci_mask_reg;
=09
pend =3D stat & mask & 0x3f;
//printk("<1>\tInt status =3D 0x%04x, mask =3D 0x%04x, pend =3D
0x%04x\n", stat, mask, pend);=09
if (!pend)
break;
for (bit =3D 0; pend !=3D 0; ++bit, pend >>=3D 1) {
if (pend & 1)
{
//printk("<1> dispatch int %d\n", PCI_INT_OFFSET + bit);
//ppc_irq_dispatch_handler(regs,
PCI_INT_OFFSET + bit);
__do_IRQ((PCI_INT_OFFSET + bit), regs);
}
}
}
return IRQ_HANDLED;
}
static struct irqaction innsys_pci_action =3D {
.handler=3D pci_irq_demux,
.flags =3D SA_INTERRUPT,
.mask =3D CPU_MASK_NONE,
.name =3D "PCI IRQ demux",
};
void
innsys_init_irq(void)
{
int irq;
void * tmp;
volatile cpm2_map_t *immap =3D cpm2_immr;
uint32_t fpga_base;
tmp =3D innsys_map_irq;
// map mask and status registers
fpga_base =3D immap->im_memctl.memc_br5 & 0xffff8000;
pci_status_reg =3D (unsigned short *)(fpga_base + PCI_INT_STAT_REG);
pci_mask_reg =3D (unsigned short *)(fpga_base + PCI_INT_MASK_REG);
=09
for (irq =3D PCI_INT_OFFSET; irq < PCI_INT_OFFSET + NUM_PCI_INTS;
irq++)
irq_desc[irq].handler =3D &innsys_ic;
/* make IRQ7 level sensitive */
((volatile cpm2_map_t *) CPM_MAP_ADDR)->im_intctl.ic_siexr &=3D
~(1 << (14 - (SIU_INT_IRQ7 - SIU_INT_IRQ1)));
=09
/* mask all PCI interrupts */
//*(volatile unsigned short *) PCI_INT_MASK_REG =3D 0;
*pci_mask_reg =3D 0;
/* install the demultiplexer for the PCI cascade interrupt */
setup_irq(SIU_INT_IRQ7, &innsys_pci_action);
return;
}
^ permalink raw reply
* PPC405 system slow boot
From: Clint Thomas @ 2006-08-28 19:56 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]
Hey guys,
I've run through the loops to try and figure what could be wrong with
this system. The board in question is modeled after the Xilinx ML300
board. It uses a Xilinx System ACE chip to load a FPGA / Kernel image
from compact flash. Originally, I was trying to use the CompactFlash as
the root file system, but because of issues in either the design or
software, this would only work if SysAce was in polled I/O mode. To
circumvent this, I built my root filesystem into an initrd image and
built a single ELF file with the Kernel and RFS, then strapped that to
the FPGA bit file to make a single FPGA/Kernel/RFS SysAce file.
Upon decompression, the Linux kernel boots quickly and loads all of the
device drivers. However when it gets to the prompt, it starts slowing
down. Output and input to and from the board becomes very very slow (it
displays 2 characters roughly every 20 seconds). Originally I believed
this to be the CPU still polling SystemAce, so I disabled the Linux
System ACE drivers to remove that as a possibility, however after doing
this, the problem still persists, even with the RFS in ram! Has anybody
encountered a similar situation to this before, with possible insight
towards a solution? Thank you for your time.
Clinton Thomas
cthomas@soneticom.com
[-- Attachment #2: Type: text/html, Size: 1769 bytes --]
^ permalink raw reply
* Re: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: Mark A. Greer @ 2006-08-28 20:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
All,
This was sent to linuxppc-embedded by Russel King. In case you missed it,
I'm forwarding it here:
Mark
--
http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/024178.html
--
asm/serial.h is supposed to contain the definitions for the architecture
specific 8250 ports for the 8250 driver. It may also define BASE_BAUD,
but this is the base baud for the architecture specific ports _only_.
Therefore, nothing other than the 8250 driver should be including this
header file. In order to move towards this goal, here is a patch which
removes some of the more obvious incorrect includes of the file.
MIPS and PPC has rather a lot of stuff in asm/serial.h, some of it looks
related to non-8250 ports. Hence, it's not trivial to conclude that
these includes are indeed unnecessary, so can mips and ppc people please
test this patch carefully.
Thanks.
diff --git a/arch/frv/kernel/setup.c b/arch/frv/kernel/setup.c
--- a/arch/frv/kernel/setup.c
+++ b/arch/frv/kernel/setup.c
@@ -31,7 +31,6 @@
#include <linux/serial_reg.h>
#include <asm/setup.h>
-#include <asm/serial.h>
#include <asm/irq.h>
#include <asm/sections.h>
#include <asm/pgalloc.h>
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -54,7 +54,6 @@
#include <asm/processor.h>
#include <asm/sal.h>
#include <asm/sections.h>
-#include <asm/serial.h>
#include <asm/setup.h>
#include <asm/smp.h>
#include <asm/system.h>
diff --git a/arch/mips/cobalt/setup.c b/arch/mips/cobalt/setup.c
--- a/arch/mips/cobalt/setup.c
+++ b/arch/mips/cobalt/setup.c
@@ -23,7 +23,6 @@
#include <asm/processor.h>
#include <asm/reboot.h>
#include <asm/gt64120.h>
-#include <asm/serial.h>
#include <asm/mach-cobalt/cobalt.h>
diff --git a/arch/mips/lasat/setup.c b/arch/mips/lasat/setup.c
--- a/arch/mips/lasat/setup.c
+++ b/arch/mips/lasat/setup.c
@@ -34,7 +34,6 @@
#include <asm/cpu.h>
#include <asm/bootinfo.h>
#include <asm/irq.h>
-#include <asm/serial.h>
#include <asm/lasat/lasat.h>
#include <asm/lasat/serial.h>
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -51,7 +51,6 @@
#include <asm/system.h>
#include <asm/rtas.h>
#include <asm/iommu.h>
-#include <asm/serial.h>
#include <asm/cache.h>
#include <asm/page.h>
#include <asm/mmu.h>
diff --git a/arch/powerpc/kernel/setup_32.c
b/arch/powerpc/kernel/setup_32.c
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -38,7 +38,6 @@
#include <asm/nvram.h>
#include <asm/xmon.h>
#include <asm/time.h>
-#include <asm/serial.h>
#include <asm/udbg.h>
#include "setup.h"
diff --git a/arch/powerpc/kernel/setup_64.c
b/arch/powerpc/kernel/setup_64.c
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -51,7 +51,6 @@
#include <asm/system.h>
#include <asm/rtas.h>
#include <asm/iommu.h>
-#include <asm/serial.h>
#include <asm/cache.h>
#include <asm/page.h>
#include <asm/mmu.h>
diff --git a/drivers/char/pcmcia/synclink_cs.c
b/drivers/char/pcmcia/synclink_cs.c
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -57,7 +57,6 @@
#include <linux/netdevice.h>
#include <linux/vmalloc.h>
#include <linux/init.h>
-#include <asm/serial.h>
#include <linux/delay.h>
#include <linux/ioctl.h>
diff --git a/drivers/char/synclink.c b/drivers/char/synclink.c
--- a/drivers/char/synclink.c
+++ b/drivers/char/synclink.c
@@ -87,7 +87,6 @@
#include <linux/vmalloc.h>
#include <linux/init.h>
-#include <asm/serial.h>
#include <linux/delay.h>
#include <linux/ioctl.h>
diff --git a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
--- a/drivers/serial/m32r_sio.c
+++ b/drivers/serial/m32r_sio.c
@@ -76,17 +76,16 @@
*/
#define is_real_interrupt(irq) ((irq) != 0)
-#include <asm/serial.h>
+#define BASE_BAUD 115200
/* Standard COM flags */
#define STD_COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST)
/*
* SERIAL_PORT_DFNS tells us about built-in ports that have no
* standard enumeration mechanism. Platforms that can find all
* serial ports via mechanisms like ACPI or PCI need not supply it.
*/
-#undef SERIAL_PORT_DFNS
#if defined(CONFIG_PLAT_USRV)
#define SERIAL_PORT_DFNS
\
@@ -109,7 +108,7 @@
#endif /* !CONFIG_PLAT_USRV */
static struct old_serial_port old_serial_port[] = {
- SERIAL_PORT_DFNS /* defined in asm/serial.h */
+ SERIAL_PORT_DFNS
};
#define UART_NR ARRAY_SIZE(old_serial_port)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* [PATCH] corrected PCI interrupt sense values to level low in mpc8349emds.dts
From: Kim Phillips @ 2006-08-28 22:49 UTC (permalink / raw)
To: linuxppc-dev
Corrected PCI interrupt sense values to level low in mpc8349emds.dts, per Leo's recommendation.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
applies on top of "[PATCH 4/4] Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts"
arch/powerpc/boot/dts/mpc8349emds.dts | 112 +++++++++++++++++----------------
1 files changed, 56 insertions(+), 56 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emds.dts b/arch/powerpc/boot/dts/mpc8349emds.dts
index 7e4508b..0643db9 100644
--- a/arch/powerpc/boot/dts/mpc8349emds.dts
+++ b/arch/powerpc/boot/dts/mpc8349emds.dts
@@ -178,46 +178,46 @@
interrupt-map = <
/* IDSEL 0x11 */
- 8800 0 0 1 700 14 0
- 8800 0 0 2 700 15 0
- 8800 0 0 3 700 16 0
- 8800 0 0 4 700 17 0
+ 8800 0 0 1 700 14 2
+ 8800 0 0 2 700 15 2
+ 8800 0 0 3 700 16 2
+ 8800 0 0 4 700 17 2
/* IDSEL 0x12 */
- 9000 0 0 1 700 16 0
- 9000 0 0 2 700 17 0
- 9000 0 0 3 700 14 0
- 9000 0 0 4 700 15 0
+ 9000 0 0 1 700 16 2
+ 9000 0 0 2 700 17 2
+ 9000 0 0 3 700 14 2
+ 9000 0 0 4 700 15 2
/* IDSEL 0x13 */
- 9800 0 0 1 700 17 0
- 9800 0 0 2 700 14 0
- 9800 0 0 3 700 15 0
- 9800 0 0 4 700 16 0
+ 9800 0 0 1 700 17 2
+ 9800 0 0 2 700 14 2
+ 9800 0 0 3 700 15 2
+ 9800 0 0 4 700 16 2
/* IDSEL 0x15 */
- a800 0 0 1 700 14 0
- a800 0 0 2 700 15 0
- a800 0 0 3 700 16 0
- a800 0 0 4 700 17 0
+ a800 0 0 1 700 14 2
+ a800 0 0 2 700 15 2
+ a800 0 0 3 700 16 2
+ a800 0 0 4 700 17 2
/* IDSEL 0x16 */
- b000 0 0 1 700 17 0
- b000 0 0 2 700 14 0
- b000 0 0 3 700 15 0
- b000 0 0 4 700 16 0
+ b000 0 0 1 700 17 2
+ b000 0 0 2 700 14 2
+ b000 0 0 3 700 15 2
+ b000 0 0 4 700 16 2
/* IDSEL 0x17 */
- b800 0 0 1 700 16 0
- b800 0 0 2 700 17 0
- b800 0 0 3 700 14 0
- b800 0 0 4 700 15 0
+ b800 0 0 1 700 16 2
+ b800 0 0 2 700 17 2
+ b800 0 0 3 700 14 2
+ b800 0 0 4 700 15 2
/* IDSEL 0x18 */
- b000 0 0 1 700 15 0
- b000 0 0 2 700 16 0
- b000 0 0 3 700 17 0
- b000 0 0 4 700 14 0>;
+ b000 0 0 1 700 15 2
+ b000 0 0 2 700 16 2
+ b000 0 0 3 700 17 2
+ b000 0 0 4 700 14 2>;
interrupt-parent = <700>;
interrupts = <42 8>;
bus-range = <0 0>;
@@ -238,46 +238,46 @@
interrupt-map = <
/* IDSEL 0x11 */
- 8800 0 0 1 700 14 0
- 8800 0 0 2 700 15 0
- 8800 0 0 3 700 16 0
- 8800 0 0 4 700 17 0
+ 8800 0 0 1 700 14 2
+ 8800 0 0 2 700 15 2
+ 8800 0 0 3 700 16 2
+ 8800 0 0 4 700 17 2
/* IDSEL 0x12 */
- 9000 0 0 1 700 16 0
- 9000 0 0 2 700 17 0
- 9000 0 0 3 700 14 0
- 9000 0 0 4 700 15 0
+ 9000 0 0 1 700 16 2
+ 9000 0 0 2 700 17 2
+ 9000 0 0 3 700 14 2
+ 9000 0 0 4 700 15 2
/* IDSEL 0x13 */
- 9800 0 0 1 700 17 0
- 9800 0 0 2 700 14 0
- 9800 0 0 3 700 15 0
- 9800 0 0 4 700 16 0
+ 9800 0 0 1 700 17 2
+ 9800 0 0 2 700 14 2
+ 9800 0 0 3 700 15 2
+ 9800 0 0 4 700 16 2
/* IDSEL 0x15 */
- a800 0 0 1 700 14 0
- a800 0 0 2 700 15 0
- a800 0 0 3 700 16 0
- a800 0 0 4 700 17 0
+ a800 0 0 1 700 14 2
+ a800 0 0 2 700 15 2
+ a800 0 0 3 700 16 2
+ a800 0 0 4 700 17 2
/* IDSEL 0x16 */
- b000 0 0 1 700 17 0
- b000 0 0 2 700 14 0
- b000 0 0 3 700 15 0
- b000 0 0 4 700 16 0
+ b000 0 0 1 700 17 2
+ b000 0 0 2 700 14 2
+ b000 0 0 3 700 15 2
+ b000 0 0 4 700 16 2
/* IDSEL 0x17 */
- b800 0 0 1 700 16 0
- b800 0 0 2 700 17 0
- b800 0 0 3 700 14 0
- b800 0 0 4 700 15 0
+ b800 0 0 1 700 16 2
+ b800 0 0 2 700 17 2
+ b800 0 0 3 700 14 2
+ b800 0 0 4 700 15 2
/* IDSEL 0x18 */
- b000 0 0 1 700 15 0
- b000 0 0 2 700 16 0
- b000 0 0 3 700 17 0
- b000 0 0 4 700 14 0>;
+ b000 0 0 1 700 15 2
+ b000 0 0 2 700 16 2
+ b000 0 0 3 700 17 2
+ b000 0 0 4 700 14 2>;
interrupt-parent = <700>;
interrupts = <42 8>;
bus-range = <0 0>;
--
1.4.1
^ permalink raw reply related
* Re: Help with booting with very large initrd
From: Reeve Yang @ 2006-08-28 23:26 UTC (permalink / raw)
To: Howard, Marc; +Cc: linuxppc-embedded
In-Reply-To: <91B22F93A880FA48879475E134D6F0BE02F33401@CA1EXCLV02.adcorp.kla-tencor.com>
[-- Attachment #1: Type: text/plain, Size: 3938 bytes --]
I had a similiar problem long time ago. I remember it was related to the
size of ramdisk. Double check if your ramdisk size big enough.
On 8/25/06, Howard, Marc <Marc.Howard@kla-tencor.com> wrote:
>
> Hi,
>
> I'm developing a PPC440GX based board that uses U-Boot to boot a
> multi-file boot image composed of the kernel and a very large (> 96MB
> uncompressed) initrd file. The board has 512MB of RAM of which the
> upper 16MB is reserved for dedicated hardware. The 16MB block is
> reserved via "mem=496M" and U-Boot is told to stay out of that area by
> setting "initrd_high=1f000000".
>
> Before anyone asks there are several reasons for doing things this way.
> NFS is not an option in the target environment.
>
> I can tftp the combined boot image to my board. I checked the crc with
> the crc32 command and it agrees exactly with the result obtained on the
> host machine using the boot file. Therefore there is not a "TFTP >32MB"
> problem here.
>
> If I boot I get the following:
>
> => boot
> Waiting for PHY auto negotiation to complete... done
> ENET Speed is 1000 Mbps - FULL duplex connection
> Using ppc_4xx_eth2 device
> TFTP from server 192.168.168.108; our IP address is 192.168.168.111
> Filename 'pMulti-ramdisk'.
> Load address: 0x400000
> Loading: *
> done
> Bytes transferred = 38825407 (2506dbf hex)
> Automatic boot of image at addr 0x00400000 ...
> ## Booting image at 00400000 ...
> Image Name: Linux-2.6.10_mvl401-440gx_eval-I
> Created: 2006-08-25 1:01:29 UTC
> Image Type: PowerPC Linux Multi-File Image (gzip compressed)
> Data Size: 38825343 Bytes = 37 MB
> Load Address: 00000000
> Entry Point: 00000000
> Contents:
> Image 0: 1137986 Bytes = 1.1 MB
> Image 1: 37687343 Bytes = 35.9 MB
> Verifying Checksum ... OK
> Uncompressing Multi-File Image ... OK
> Loading Ramdisk to 1cc0e000, end 1efff02f ... OK
> Linux version 2.6.10_mvl401-440gx_eval (cram@toaster.kla-tencor.com)
> (gcc version 3.4.3 (MontaVista 3.4.3-25.0.107.0601076 2006-07-21)) #46
> Thu Aug 24 17:28:09 PDT 2006
> IBM Ocotea port (MontaVista Software, Inc. <source@mvista.com>)
> Built 1 zonelists
> Kernel command line: ramdisk_size=262144 root=/dev/ram rw
> console=ttyS0,115200
> ip=192.168.168.111:192.168.168.108::255.255.255.0:scpu2:eth0: off
> mem=496M
> PID hash table entries: 2048 (order: 11, 32768 bytes)
>
> ......stuff deleted......
>
> RAMDISK driver initialized: 8 RAM disks of 262144K size 1024 blocksize
> loop: loaded (max 8 devices)
>
> ......more stuff deleted......
>
> eth0: link is down
> eth0: link is up, 1000 FDX, pause enabled
> IP-Config: Complete:
> device=eth0, addr=192.168.168.111, mask=255.255.255.0,
> gw=255.255.255.255, host=scpu2, domain=, nis-domain=(none),
> bootserver=192.168.168.108, rootserver=192.168.168.108, rootpath=
> RAMDISK: Compressed image found at block 0
> crc error (orig 0x9a278d64, CRC_VALUE 0xa7bcd2e3 -- ignoring!
> length error (orig = 0x0c000000, bytes_out = 0x0c000015 -- ignored
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 120k init
> Warning: unable to open an initial console.
> Kernel panic - not syncing: No init found. Try passing init= option to
> kernel.
> <0>Rebooting in 180 seconds..
>
> (I modified lib/inflate.c so that the crc and length checks would
> provide more info).
>
> Since the overall file CRC is good and U-Boot checksums are also okay
> this looks like some sort of size limitation with the inflate routine.
> BTW, The kerenel was made assuming a 256MB ramdisk; likewise the command
> line specs one as well. The initrd image would fit easily in that
> space.
>
> Have any of you worked on this problem before and come up with a
> solution?
>
> Thanks,
>
> Marc Howard
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 5268 bytes --]
^ permalink raw reply
* MPC83xx and Gianfar Drive Oops
From: SIP COP 009 @ 2006-08-28 23:33 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: sipcop009
[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]
Folks,
Anyone seen this before ?
We have the MPC8349 based EVM board which has 2 GigEs. IP forwarding is
enabled on the system. The kernel/gianfar is 2.6.11 based.
We were trying to stress the GigE interfaces by sending bidirectional
smartbits traffic.
We observe the following kernel oops:
e-99-0-21-1# Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C016EB80 LR: C016EB80 SP: C0241DE0 REGS: c0241d30 TRAP: 0700
Tainted: P
MSR: 00029032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c022bdb0[0] 'swapper'
THREAD: c0240000 Last syscall: 120
GPR00: C016EB80 C0241DE0 C022BDB0 00000030 C0263BF4 000001A1 DF700060
3B9ACA00
GPR08: C0263BF8 C023DB24 DEA5DE9C C0241CF0 00003C9B 1001A1F8 1FFF8000
00000000
GPR16: FFFFFFFF 00000001 00000000 1FFF297C 1FF9E330 00000001 007FFF00
C0230000
GPR24: 00000001 0000FFFC DFD6B800 0000003F DDC42F48 00000000 D7FA9140
DFD6BA20 Call trace: [c01495d4] [c0149748] [c0176078] [c0018d34]
[c0018e00] [c0005438] [c000460c] [c00038ac] [c00054d0] [c0003928]
[c0242674] [000035fc] Kernel panic - not syncing: Aiee, killing interrupt
handler!
<0>Rebooting in 180 seconds..
After decoding this it looks like the following:
Enter hex value: c01495d4
0xc01495d4:gfar_error(0xc01494bc)+0x118
Enter hex value: c0149748
0xc0149748:gfar_gdrvinfo(0xc0149718)+0x30
Enter hex value: c0176078
0xc0176078:dev_ioctl(0xc0175f0c)+0x16c
Enter hex value: c0018d34
0xc0018d34:__do_softirq(0xc0018cb4)+0x80
Enter hex value: c0018e00
0xc0018e00:do_softirq(0xc0018da8)+0x58
Enter hex value: c0005438
0xc0005438:do_IRQ(0xc00053b4)+0x84
Enter hex value: c000460c
0xc000460c:ret_from_except(0xc000460c)+0x0
Enter hex value: c00038ac
0xc00038ac:ppc6xx_idle(0xc00037c8)+0xe4
Enter hex value: c00054d0
0xc00054d0:cpu_idle(0xc00054a8)+0x28
Any idea on this one ? Any new fixes that went in for such issues ?
Thanks!
ashutosh
[-- Attachment #2: Type: text/html, Size: 2075 bytes --]
^ permalink raw reply
* Re: How to boot powerPC linux-2.6.10 from diifferent address other than 0x0000
From: Reeve Yang @ 2006-08-28 23:37 UTC (permalink / raw)
To: Reddy Suneel-ASR125; +Cc: linuxppc-embedded
In-Reply-To: <405ECA8A30557F439A723E52D50838F9D372AB@ZMY16EXM66.ds.mot.com>
[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]
You need to do two things:
- mem remap your boot sector memory block to virtual address 0xc0008000
- using uboot commond "go xxx" to boot it from 0xc0008000, or define env
variable "bootcmd", and run "boot".
On 8/25/06, Reddy Suneel-ASR125 <suneel.reddy@motorola.com> wrote:
>
> Hi,
> We are working on MPC 8540, Linux kernel version is 2.6.10 from
> Montavista. The bootloader used in Uboot and currently it loads the uImage
> at physical memory address 0x0 and transfers control to it. We want to load
> the kernel at a different address say 0x8000 and for this we made the
> following changes.
>
> 1) Altered the Makefile to linked the kernel at virtual address 0xc0008000
> ( the default was 0xc000:0000)
> 2) Modified Uboot to load kernel at 0x8000 instead of 0x0
>
> The kernel space still starts from 0xc000:0000
>
> When we transferred control to the kernel (loaded at 0x8000) we found that
> the execution proceeds only till the mapping and invalidation on TLBs. We do
> not know where the control goes after this as the further instructions does
> not seems to get executed. Currently we do not have the provision to connect
> a debugger and hence we are unable to make out what is happening.
>
> Can some one give us any clue as to what we might have done wrong? This is
> our first experience on PowerPC.
>
>
> Thanks®ards
> Suneel
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
[-- Attachment #2: Type: text/html, Size: 3256 bytes --]
^ 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