* 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
* Re: copy_4K_page() doesn't use dcbtst?
From: Paul Mackerras @ 2006-08-29 0:16 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, xen-ppc-devel
In-Reply-To: <1156786523.28490.52.camel@basalt.austin.ibm.com>
Hollis Blanchard writes:
> 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?
Why would we want to read the cache lines for the destination from
memory when we're only going to overwrite them completely anyway?
A stronger argument would be for using dcbz, but IIRC it actually made
things slower (on POWER4 at least). I suspect the hardware is
gathering the stores for the whole of each cache line automatically,
so using dcbz doesn't provide any benefit.
I did a lot of measurements of memory copy speed on POWER4 (using
different copy loops, copy sizes, alignments, cache hot/cold cases)
and the copy_4K_page loop is the fastest I could come up with for
POWER4. If anyone can come up with a routine that is measurably
faster on current machines, I'm happy to look at it, of course.
Paul.
^ permalink raw reply
* RE: atomic operations in user space
From: Xupei Liang @ 2006-08-29 0:43 UTC (permalink / raw)
To: linuxppc-embedded
I think it is less expensive using atomic operation
sometimes in the user space, e.g. when updating a
counter. If this counter is to be updated by a lot of
processes, using semaphore can potentially cause a lot
of task switching.
Regards,
Terry Liang
> -----Original Message-----
> From: Brent Cook [mailto:bcook at bpointsys.com]
> Sent: Thursday, August 24, 2006 10:18 PM
> To: linuxppc-embedded at ozlabs.org
> Cc: Li Yang-r58472; Terry Liang
> Subject: Re: atomic operations in user space
>
> On Thursday 24 August 2006 05:39, Li Yang-r58472
wrote:
>
> > Why do you need atomic operations in user land?
IPC will be
sufficient
>
> > to deal with race conditions between processes.
>
> >
>
> > Best Regards,
>
> > Leo
>
> What about multiple threads within a process
updating a counter?
Is there anything preventing semaphore to be used in
threads?
>
> Of course, if you look at these functions in the
kernel header,
they're just 2 or
> 3 inline assembly calls - you could easily rewrite
them. Google for
'PowerPC atomic
> increment' and grab one of the unencumbered
implementations if you
need to use it
> in a non-GPL program.
>
> On the other hand, I see no license at the top of my
/usr/include/asm-i386/atomic.h
> file at all, same for PowerPC - are Linux header
files actually GPL or
are they
> more like the glibc headers, with exceptions made
for userspace
programs?
>
> The atomic operations on x86 were accidentally
exported early on, so
they have to
> hang around apparently for compatibility (there are
some mailing list
threads out
> there to this effect.) Currently, you just have to
assume in Linux
that if you
> include something from /usr/include/linux or asm
that it will not
necessarily be
> cross-version or cross-architecture compatible. Not
every arch in
Linux even has
> atomic operations of this nature, which I guess is
the main reason why
they are
> not exported in general.
>
> - Brent
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: PPC405 system slow boot
From: Peter Ryser @ 2006-08-29 0:45 UTC (permalink / raw)
To: Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952918E1E2@bluefin.Soneticom.local>
[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]
Clint,
check the interrupt sub-system of your design. What you describe
typically happens when the PPC does not get any interrupts from the
UART. It's most likely a mismatch between your hardware and the
xparameters.h.
- Peter
Clint Thomas wrote:
> 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
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2704 bytes --]
^ permalink raw reply
* PPC 2.6.11.4 kernel panics while doing insmod (store fault with d cbst in icache_flush_range)
From: Kallol Biswas @ 2006-08-29 1:53 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: Ronald Lee, linuxppc-dev, Radjendirane Codandaramane, Shawn Jin
I have been getting an "oops" while doing insmod.
Sys_init_module() -> Load_module() -> module_alloc(mod->core_size)
Mod->core_size is = 0x1ff4
A few lines from module_alloc() routine:
ptr = module_alloc(mod->core_size); // core_size is 0x1ff4
if (!ptr) {
err = -ENOMEM;
goto free_percpu;
}
memset(ptr, 0, mod->core_size);
mod->module_core = ptr;
Module_alloc calls vmalloc, which populates the page tables entries; no TLB entry is updated at this moment for the newly vmalloc'd memory.
Next, when memset is done, we do see two TLB entries are allocated one for each page (ptr == D21B8000, core_size being 0x1ff4 we need two pages).
0x0000-0000
0xD21B-8210
0x0063-B000
0x0000-0107
0x0000-0000
0xD21B-9210
0x0063-7000
0x0000-0107
A few lines from sys_init_module()
/* Do all the hard work */
mod = load_module(umod, len, uargs);
if (IS_ERR(mod)) {
up(&module_mutex);
return PTR_ERR(mod);
}
/* Flush the instruction cache, since we've played with text */
if (mod->module_init)
flush_icache_range((unsigned long)mod->module_init,
(unsigned long)mod->module_init
+ mod->init_size);
flush_icache_range((unsigned long)mod->module_core,
(unsigned long)mod->module_core + mod->core_size);
Next, at the routine
flush_icache_range((unsigned long)mod->module_core,
(unsigned long)mod->module_core + mod->core_size);
we see that one of the TLB entries is not present, which is probably normal.
A few lines from flush_icache_range():
mr r6,r3
1: dcbst 0,r3
addi r3,r3,L1_CACHE_LINE_SIZE
bdnz 1b
The instruction takes a store fault (DST bit, bit 8 of ESR gets set), kernel panics with oops (signal 11).
It is probably normal that the TLB entry for vmalloc'd memory may not be present.
How do we fix the problem?
We do see the problem only when we have big drivers compiled into the kernel.
Thanks,
Kallol
^ 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