* [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add instrumentation
From: Mike Kravetz @ 2006-07-21 6:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721063824.GA8639@monkey.ibm.com>
Gather snapshots in the hcall routines and make callout to update data.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr linux-2.6.17-rc6/arch/powerpc/Kconfig.debug linux-2.6.17-rc6.work/arch/powerpc/Kconfig.debug
--- linux-2.6.17-rc6/arch/powerpc/Kconfig.debug 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/Kconfig.debug 2006-06-13 21:39:24.000000000 +0000
@@ -18,6 +18,16 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat.
+config HCALL_STATS
+ bool "Hypervisor call instrumentation"
+ depends on PPC_PSERIES
+ help
+ Adds code to keep track of number of hypervisor calls made and
+ the amount of time spent in hypervisor calls.
+
+ This option will add a small amount of overhead to all hypervisor
+ calls.
+
config DEBUGGER
bool "Enable debugger hooks"
depends on DEBUG_KERNEL
diff -Naupr linux-2.6.17-rc6/arch/powerpc/platforms/pseries/Makefile linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/Makefile
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/Makefile 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/Makefile 2006-06-13 21:39:24.000000000 +0000
@@ -9,3 +9,4 @@ obj-$(CONFIG_EEH) += eeh.o eeh_cache.o e
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
+obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
diff -Naupr linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall.S linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall.S
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall.S 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall.S 2006-06-13 21:39:24.000000000 +0000
@@ -25,7 +25,11 @@
unsigned long *out2, R9
unsigned long *out3); R10
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_base)
+#else
_GLOBAL(plpar_hcall)
+#endif
HMT_MEDIUM
mfcr r0
@@ -52,7 +56,15 @@ _GLOBAL(plpar_hcall)
/* Simple interface with no output values (other than status) */
+#ifdef CONFIG_HCALL_STATS
_GLOBAL(plpar_hcall_norets)
+ b plpar_hcall_norets_C
+
+
+_GLOBAL(plpar_hcall_norets_base)
+#else
+_GLOBAL(plpar_hcall_norets)
+#endif
HMT_MEDIUM
mfcr r0
@@ -76,7 +88,11 @@ _GLOBAL(plpar_hcall_norets)
unsigned long arg8, 112(R1)
unsigned long *out1); 120(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_8arg_2ret_base)
+#else
_GLOBAL(plpar_hcall_8arg_2ret)
+#endif
HMT_MEDIUM
mfcr r0
@@ -102,7 +118,11 @@ _GLOBAL(plpar_hcall_8arg_2ret)
unsigned long *out3, R10
unsigned long *out4); 112(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_4out_base)
+#else
_GLOBAL(plpar_hcall_4out)
+#endif
HMT_MEDIUM
mfcr r0
@@ -144,7 +164,11 @@ _GLOBAL(plpar_hcall_4out)
unsigned long *out6, 102(R1)
unsigned long *out7); 100(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_7arg_7ret_base)
+#else
_GLOBAL(plpar_hcall_7arg_7ret)
+#endif
HMT_MEDIUM
mfcr r0
@@ -193,7 +217,11 @@ _GLOBAL(plpar_hcall_7arg_7ret)
unsigned long *out8, 94(R1)
unsigned long *out9, 92(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_9arg_9ret_base)
+#else
_GLOBAL(plpar_hcall_9arg_9ret)
+#endif
HMT_MEDIUM
mfcr r0
diff -Naupr linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall_inst.c linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall_inst.c 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-06-13 21:39:24.000000000 +0000
@@ -0,0 +1,239 @@
+/*
+ * Copyright (C) 2006 Mike Kravetz IBM Corporation
+ *
+ * Hypervisor Call Instrumentation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/percpu.h>
+#include <asm/hvcall.h>
+
+DEFINE_PER_CPU(struct hcall_stats[MAX_HCALL_OPCODES+1], hcall_stats);
+
+static inline void update_stats(unsigned long opcode, unsigned long t_before)
+{
+ unsigned long op_index= opcode >> 2;
+ struct hcall_stats *hs = &__get_cpu_var(hcall_stats[op_index]);
+
+ /* racey, but acceptable for non-critical stats */
+ hs->total_time += (mfspr(SPRN_PURR) - t_before);
+ hs->num_calls++;
+}
+
+extern long plpar_hcall_base (unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3);
+
+long plpar_hcall(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_base(opcode, arg1, arg2, arg3, arg4, out1, out2, out3);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_norets_base(unsigned long opcode, ...);
+
+long plpar_hcall_norets_C(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_norets_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_8arg_2ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1);
+
+long plpar_hcall_8arg_2ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_8arg_2ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, out1);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_4out_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4);
+
+long plpar_hcall_4out(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_4out_base(opcode, arg1, arg2, arg3, arg4, out1,
+ out2, out3, out4);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_7arg_7ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7);
+
+long plpar_hcall_7arg_7ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_7arg_7ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, out1, out2, out3, out4,
+ out5, out6, out7);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_9arg_9ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9);
+
+long plpar_hcall_9arg_9ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_9arg_9ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, arg9, out1, out2,
+ out3, out4, out5, out6, out7, out8,
+ out9);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
diff -Naupr linux-2.6.17-rc6/include/asm-powerpc/hvcall.h linux-2.6.17-rc6.work/include/asm-powerpc/hvcall.h
--- linux-2.6.17-rc6/include/asm-powerpc/hvcall.h 2006-06-13 21:38:45.000000000 +0000
+++ linux-2.6.17-rc6.work/include/asm-powerpc/hvcall.h 2006-06-13 21:39:24.000000000 +0000
@@ -292,6 +292,13 @@ long plpar_hcall_9arg_9ret(unsigned long
unsigned long *out8,
unsigned long *out9);
+#ifdef CONFIG_HCALL_STATS
+struct hcall_stats {
+ unsigned long num_calls;
+ unsigned long total_time;
+};
+#endif /* CONFIG_HCALL_STATS */
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add instrumentation
From: Mike Kravetz @ 2006-07-21 6:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721064153.GC8639@monkey.ibm.com>
On Thu, Jul 20, 2006 at 11:41:53PM -0700, Mike Kravetz wrote:
> Gather snapshots in the hcall routines and make callout to update data.
Wrong patch!!!! Sorry! Here is the correct one.
Gather snapshots in the hcall routines and make callout to update data.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr powerpc/arch/powerpc/Kconfig.debug powerpc.work/arch/powerpc/Kconfig.debug
--- powerpc/arch/powerpc/Kconfig.debug 2006-07-19 18:45:58.000000000 +0000
+++ powerpc.work/arch/powerpc/Kconfig.debug 2006-07-21 07:06:49.000000000 +0000
@@ -18,6 +18,20 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat.
+config HCALL_STATS
+ bool "Hypervisor call instrumentation"
+ depends on PPC_PSERIES && DEBUG_FS
+ help
+ Adds code to keep track of the number of hypervisor calls made and
+ the amount of time spent in hypervisor calls: both wall time (based
+ on time base) and cpu time (based on PURR). A directory named
+ hcall_inst is added at the root of the debugfs filesystem. Within
+ the hcall_inst directory are files that contain CPU specific call
+ statistics.
+
+ This option will add a small amount of overhead to all hypervisor
+ calls.
+
config DEBUGGER
bool "Enable debugger hooks"
depends on DEBUG_KERNEL
diff -Naupr powerpc/arch/powerpc/platforms/pseries/Makefile powerpc.work/arch/powerpc/platforms/pseries/Makefile
--- powerpc/arch/powerpc/platforms/pseries/Makefile 2006-07-19 18:46:08.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/Makefile 2006-07-21 07:06:49.000000000 +0000
@@ -12,3 +12,4 @@ obj-$(CONFIG_EEH) += eeh.o eeh_cache.o e
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
+obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
diff -Naupr powerpc/arch/powerpc/platforms/pseries/hvCall.S powerpc.work/arch/powerpc/platforms/pseries/hvCall.S
--- powerpc/arch/powerpc/platforms/pseries/hvCall.S 2006-07-19 18:58:18.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/hvCall.S 2006-07-21 07:06:49.000000000 +0000
@@ -11,7 +11,57 @@
#include <asm/processor.h>
#include <asm/ppc_asm.h>
-#define STK_PARM(i) (48 + ((i)-3)*8)
+#define STK_PARM(i) (STACKFRAMESIZE + 48 + ((i)-3)*8)
+#define STK_REG(i) (112 + ((i)-14)*8)
+
+#ifdef CONFIG_HCALL_STATS
+#define STACKFRAMESIZE 256
+#define HCALL_INST_PRECALL \
+ /* use stack frame to save a few non-volital regs */ \
+ stdu r1,-STACKFRAMESIZE(r1); \
+ std r31,STK_REG(r31)(r1); \
+ std r30,STK_REG(r30)(r1); \
+ std r29,STK_REG(r29)(r1); \
+ std r28,STK_REG(r28)(r1); \
+ \
+ /* save lr and hcall opcode */ \
+ /* then get time, purr snapshot before hcall */ \
+ mflr r31; \
+ mr r30,r3; \
+ mftb r29; \
+BEGIN_FTR_SECTION; \
+ mfspr r28,SPRN_PURR; \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR);
+
+#define HCALL_INST_POSTCALL \
+ /* get time, purr snapshot after hcall */ \
+ mftb r4; \
+BEGIN_FTR_SECTION; \
+ mfspr r5,SPRN_PURR; \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
+ \
+ /* setup regs to call routine that stuffs stats */ \
+ /* into per-cpu/per-call structure. */ \
+ subf r4,r29,r4; \
+ subf r5,r28,r5; \
+ mr r29,r3; /* save hcall rc */ \
+ mr r3,r30; \
+ bl .update_hcall_stats; \
+ \
+ /* restore hcall rc, lr and non-volital regs */ \
+ mr r3,r29; \
+ mtlr r31; \
+ ld r31,STK_REG(r31)(r1); \
+ ld r30,STK_REG(r30)(r1); \
+ ld r29,STK_REG(r29)(r1); \
+ ld r28,STK_REG(r28)(r1); \
+ addi r1,r1,STACKFRAMESIZE
+#else
+
+#define STACKFRAMESIZE 0
+#define HCALL_INST_PRECALL nop
+#define HCALL_INST_POSTCALL nop
+#endif
.text
@@ -21,8 +71,12 @@ _GLOBAL(plpar_hcall_norets)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
HVSC /* invoke the hypervisor */
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
blr /* return r3 = status */
@@ -33,6 +87,8 @@ _GLOBAL(plpar_hcall)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
std r4,STK_PARM(r4)(r1) /* Save ret buffer */
mr r4,r5
@@ -50,6 +106,8 @@ _GLOBAL(plpar_hcall)
std r6, 16(r12)
std r7, 24(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
@@ -61,6 +119,8 @@ _GLOBAL(plpar_hcall9)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
std r4,STK_PARM(r4)(r1) /* Save ret buffer */
mr r4,r5
@@ -86,6 +146,8 @@ _GLOBAL(plpar_hcall9)
std r11,56(r12)
std r12,64(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
diff -Naupr powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c 1970-01-01 00:00:00.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-21 07:08:40.000000000 +0000
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C) 2006 Mike Kravetz IBM Corporation
+ *
+ * Hypervisor Call Instrumentation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/percpu.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
+#include <linux/cpumask.h>
+#include <asm/hvcall.h>
+#include <asm/firmware.h>
+
+DEFINE_PER_CPU(struct hcall_stats[MAX_HCALL_OPCODES+1], hcall_stats);
+
+/*
+ * Common update of the per-CPU/per-hcall statistics
+ */
+void update_hcall_stats(unsigned long opcode,
+ unsigned long tb_delta,
+ unsigned long purr_delta)
+{
+ unsigned long op_index = opcode >> 2;
+ struct hcall_stats *hs = &__get_cpu_var(hcall_stats[op_index]);
+
+ hs->tb_total += tb_delta;
+ hs->purr_total += purr_delta;
+ hs->num_calls++;
+}
diff -Naupr powerpc/include/asm-powerpc/hvcall.h powerpc.work/include/asm-powerpc/hvcall.h
--- powerpc/include/asm-powerpc/hvcall.h 2006-07-21 07:04:39.000000000 +0000
+++ powerpc.work/include/asm-powerpc/hvcall.h 2006-07-21 07:06:49.000000000 +0000
@@ -246,6 +246,15 @@ long plpar_hcall(unsigned long opcode, u
#define PLPAR_HCALL9_BUFSIZE 9
long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...);
+/* For hcall instrumentation. One structure per-hcall, per-CPU */
+struct hcall_stats {
+ unsigned long num_calls; /* number of calls (on this CPU) */
+ unsigned long tb_total; /* total wall time (mftb) of calls. */
+ unsigned long purr_total; /* total cpu time (PURR) of calls. */
+};
+void update_hcall_stats(unsigned long opcode, unsigned long tb_delta,
+ unsigned long purr_delta);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
^ permalink raw reply
* [PATCH 3/3] powerpc: Instrument Hypervisor Calls: add debugfs file
From: Mike Kravetz @ 2006-07-21 6:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721063824.GA8639@monkey.ibm.com>
Make statistics available via files in debugfs.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-21 07:10:08.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-21 07:11:00.000000000 +0000
@@ -42,3 +42,96 @@ void update_hcall_stats(unsigned long op
hs->purr_total += purr_delta;
hs->num_calls++;
}
+
+/*
+ * Routines for displaying the statistics in debugfs
+ */
+static void *hc_start(struct seq_file *m, loff_t *pos)
+{
+ if ((int)*pos < MAX_HCALL_OPCODES)
+ return (void *)(unsigned long)(*pos + 1);
+
+ return NULL;
+}
+
+static void *hc_next(struct seq_file *m, void *p, loff_t * pos)
+{
+ ++*pos;
+
+ return hc_start(m, pos);
+}
+
+static void hc_stop(struct seq_file *m, void *p)
+{
+}
+
+static int hc_show(struct seq_file *m, void *p)
+{
+ unsigned long h_num = (unsigned long)p;
+ struct hcall_stats *hs = (struct hcall_stats *)m->private;
+
+ if (hs[h_num].num_calls)
+ seq_printf(m, "%lu %lu %lu %lu\n", h_num<<2,
+ hs[h_num].num_calls,
+ hs[h_num].tb_total,
+ hs[h_num].purr_total);
+
+ return 0;
+}
+
+static struct seq_operations hcall_inst_seq_ops = {
+ .start = hc_start,
+ .next = hc_next,
+ .stop = hc_stop,
+ .show = hc_show
+};
+
+static int hcall_inst_seq_open(struct inode *inode, struct file *file)
+{
+ int rc;
+ struct seq_file *seq;
+
+ rc = seq_open(file, &hcall_inst_seq_ops);
+ seq = file->private_data;
+ seq->private = file->f_dentry->d_inode->u.generic_ip;
+
+ return rc;
+}
+
+static struct file_operations hcall_inst_seq_fops = {
+ .open = hcall_inst_seq_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
+#define HCALL_ROOT_DIR "hcall_inst"
+#define CPU_NAME_BUF_SIZE 32
+
+static int __init hcall_inst_init(void)
+{
+ struct dentry *hcall_root;
+ struct dentry *hcall_file;
+ char cpu_name_buf[CPU_NAME_BUF_SIZE];
+ int cpu;
+
+ if (!firmware_has_feature(FW_FEATURE_LPAR))
+ return 0;
+
+ hcall_root = debugfs_create_dir(HCALL_ROOT_DIR, NULL);
+ if (!hcall_root)
+ return -ENOMEM;
+
+ for_each_possible_cpu(cpu) {
+ snprintf(cpu_name_buf, CPU_NAME_BUF_SIZE, "cpu%d", cpu);
+ hcall_file = debugfs_create_file(cpu_name_buf, S_IRUGO,
+ hcall_root,
+ per_cpu(hcall_stats, cpu),
+ &hcall_inst_seq_fops);
+ if (!hcall_file)
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+__initcall(hcall_inst_init);
^ permalink raw reply
* Can't "up" my eth0
From: Denny @ 2006-07-21 7:03 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1151373673.26257.194.camel@mindpipe>
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
Hi,
I am now succefully to bring up my kernel on my PPC440GP custom board, but I failed to up my eth0, the eth0 is link down after the kernel is booting up.
There is no effect, after the command ifconfig eth0 up.
Can anyone tell me what may be the root case, and what reason may cause the eth0 unstable, thanks a lot.
below is my log:
PPC 4xx OCP EMAC driver, version 3.53
mal0: initialized, 4 TX channels, 2 RX channels
zmii0: bridge in RMII mode
eth0: emac0, MAC 00:01:02:54:12:47
eth0: found Generic MII PHY (0x01)
emac1: can't find PHY!
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 120k init
Starting pid 22, console /dev/teth0: link is down
Starting pid 27, console /dev/ttyS1: '/bin/bash'
Starting pid 26, console /dev/ttyS1: '/bin/application'
### Application running ...
Starting pid 29, console /dev/ttyS1: '/bin/application'
Thanks in advance!
- Denny
[-- Attachment #2: Type: text/html, Size: 2241 bytes --]
^ permalink raw reply
* [PATCH 1/3] powerpc: Instrument Hypervisor Calls: merge headers
From: Mike Kravetz @ 2006-07-21 6:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721063824.GA8639@monkey.ibm.com>
Move all the Hypervisor call definitions to to a single header file.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr powerpc/drivers/net/ibmveth.h powerpc.work/drivers/net/ibmveth.h
--- powerpc/drivers/net/ibmveth.h 2006-07-19 18:58:18.000000000 +0000
+++ powerpc.work/drivers/net/ibmveth.h 2006-07-21 07:03:44.000000000 +0000
@@ -41,16 +41,6 @@
#define IbmVethMcastRemoveFilter 0x2UL
#define IbmVethMcastClearFilterTable 0x3UL
-/* hcall numbers */
-#define H_VIO_SIGNAL 0x104
-#define H_REGISTER_LOGICAL_LAN 0x114
-#define H_FREE_LOGICAL_LAN 0x118
-#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
-#define H_SEND_LOGICAL_LAN 0x120
-#define H_MULTICAST_CTRL 0x130
-#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
-#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
-
/* hcall macros */
#define h_register_logical_lan(ua, buflst, rxq, fltlst, mac) \
plpar_hcall_norets(H_REGISTER_LOGICAL_LAN, ua, buflst, rxq, fltlst, mac)
diff -Naupr powerpc/include/asm-powerpc/hvcall.h powerpc.work/include/asm-powerpc/hvcall.h
--- powerpc/include/asm-powerpc/hvcall.h 2006-07-19 18:58:18.000000000 +0000
+++ powerpc.work/include/asm-powerpc/hvcall.h 2006-07-21 07:03:44.000000000 +0000
@@ -164,9 +164,15 @@
#define H_VIO_SIGNAL 0x104
#define H_SEND_CRQ 0x108
#define H_COPY_RDMA 0x110
+#define H_REGISTER_LOGICAL_LAN 0x114
+#define H_FREE_LOGICAL_LAN 0x118
+#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
+#define H_SEND_LOGICAL_LAN 0x120
+#define H_MULTICAST_CTRL 0x130
#define H_SET_XDABR 0x134
#define H_STUFF_TCE 0x138
#define H_PUT_TCE_INDIRECT 0x13C
+#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
#define H_VTERM_PARTNER_INFO 0x150
#define H_REGISTER_VTERM 0x154
#define H_FREE_VTERM 0x158
@@ -196,11 +202,13 @@
#define H_GET_HCA_INFO 0x1B8
#define H_GET_PERF_COUNT 0x1BC
#define H_MANAGE_TRACE 0x1C0
+#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
#define H_JOIN 0x298
#define H_VASI_STATE 0x2A4
#define H_ENABLE_CRQ 0x2B0
+#define MAX_HCALL_OPCODES (H_ENABLE_CRQ >> 2)
#ifndef __ASSEMBLY__
^ permalink raw reply
* [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-07-21 6:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Here is a version of the instrumentation patches built on top of
Anton's hcall cleanup patch. In addition, I have gathered the
timebase and PURR snapshots in assembly code. However, it still
performs a call out to C code that updates the data structures.
I'd appreciate some comments on the assembly code as it has been
a looooong time since I've written any.
--
Mike
^ permalink raw reply
* Boot strategies and Boot Image formats in arch/powerpc
From: Claus Gindhart @ 2006-07-21 9:35 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Olaf Wepner, Sabine Bielski, Stefan Nickl
[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]
Hi all,
currently i am trying to migrate our existing PowerPC board supports from the arch/ppc - directory into the new arch/powerpc. I am directly working within a cloned paulus_powerpc git repository on the most recent status.
We (Kontron) want to bring our kernel sources into the appropriate for an open source submission. We are modifying both our proprietary Bootloader, and the Linux Kernel, to make them fit to the new conventions, e.g. the flattened device tree.
However, i dont understand the following:
In the old structure, the kernel provided a bunch of sub directories (simple,openfirmware,...) to create a wrapper around the Linux kernel for brining it into the format, which is appropriate for the boot loader used.
This structure was easily adaptable for custom image formats.
Now, these dirs dont exist any more.
What is the strategy here (i could assume one the 3 variants below ?
a) Is it now in the responsibility of the bootloader, to support one of the image formats,
which can be generated here currently ?
b) Will these subdirs (e.g. "simple") come here, but just where not ported yet ?
c) Or, shall such wrapper around the kernel, and/or bringing the kernel into a particular file format
be performed outside the kernel source, by proprietary tools
(e.g. like U-boot does it with the mkimage tool) ?
--
Mit freundlichen Gruessen / Best regards
Claus Gindhart
SW R&D
Kontron Modular Computers
phone :++49 (0)8341-803-374
mailto:claus.gindhart@kontron-modular.com
http://www.kontron.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
D-- G e++> h--- !r x+++
------END GEEK CODE BLOCK------
[-- Attachment #2: Type: text/html, Size: 3578 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: Instrument Hypervisor Calls: merge headers
From: Stephen Rothwell @ 2006-07-21 12:14 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060721063951.GB8639@monkey.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]
Hi Paulus,
On Thu, 20 Jul 2006 23:39:51 -0700 Mike Kravetz <kravetz@us.ibm.com> wrote:
>
> Move all the Hypervisor call definitions to to a single header file.
> --
> Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
Can you put this one in immediately just to save Mike having to repost it :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Boot strategies and Boot Image formats in arch/powerpc
From: Vitaly Bordug @ 2006-07-21 14:16 UTC (permalink / raw)
To: Claus Gindhart
Cc: Olaf Wepner, Sabine Bielski, Stefan Nickl, linuxppc-embedded
In-Reply-To: <DADA32856852FC458E0F96B664A6F55E011E239F@kom-mailsrv1.kontron-modular.com>
On Fri, 21 Jul 2006 11:35:25 +0200
"Claus Gindhart" <claus.gindhart@kontron.com> wrote:
> Hi all,
>
> currently i am trying to migrate our existing PowerPC board supports from the arch/ppc - directory into the new arch/powerpc. I am directly working within a cloned paulus_powerpc git repository on the most recent status.
>
> We (Kontron) want to bring our kernel sources into the appropriate for an open source submission. We are modifying both our proprietary Bootloader, and the Linux Kernel, to make them fit to the new conventions, e.g. the flattened device tree.
>
> However, i dont understand the following:
>
> In the old structure, the kernel provided a bunch of sub directories (simple,openfirmware,...) to create a wrapper around the Linux kernel for brining it into the format, which is appropriate for the boot loader used.
> This structure was easily adaptable for custom image formats.
>
> Now, these dirs dont exist any more.
Well, in arch/powerpc those stuff had no sense so far.. But it may change - see below.
>
> What is the strategy here (i could assume one the 3 variants below ?
>
> a) Is it now in the responsibility of the bootloader, to support one of the image formats,
> which can be generated here currently ?
>
This way we have started with powerpc merge and it still could be used. there are plenty of such stuff in the list archives, being discussed, and even followed up with patches.
But that imply u-boot firmware so not interesting for you I assume.
> b) Will these subdirs (e.g. "simple") come here, but just where not ported yet ?
>
Currently, Mark is working on a thing similar to this case. the kernel building zImage has to compile devicetree to binary dtb and line stuff up so that booting, the shim has started the kernel and have devicetree passed to it.
> c) Or, shall such wrapper around the kernel, and/or bringing the kernel into a particular file format
> be performed outside the kernel source, by proprietary tools
> (e.g. like U-boot does it with the mkimage tool) ?
>
This was yet another way pondered, but I guess b) looked better.
> --
> Mit freundlichen Gruessen / Best regards
>
> Claus Gindhart
> SW R&D
> Kontron Modular Computers
> phone :++49 (0)8341-803-374
> mailto:claus.gindhart@kontron-modular.com
> http://www.kontron.com
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
> K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
> D-- G e++> h--- !r x+++
> ------END GEEK CODE BLOCK------
>
>
>
>
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* RE: AltiVec in the kernel
From: Matt Sealey @ 2006-07-21 14:42 UTC (permalink / raw)
To: 'Brian D. Carlstrom', 'Olof Johansson'
Cc: 'linuxppc-dev list', 'Paul Mackerras'
In-Reply-To: <lezmf4j5ym.wl%bdc@carlstrom.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+matt=genesi-usa.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+matt=genesi-usa.com@ozlabs.org]
> On Behalf Of Brian D. Carlstrom
> Sent: Thursday, July 20, 2006 4:57 PM
> To: Olof Johansson
> Cc: 'Paul Mackerras'; 'linuxppc-dev list'
> Subject: Re: AltiVec in the kernel
>
> At Thu, 20 Jul 2006 14:05:23 -0500, Olof Johansson wrote:
> > On Thu, Jul 20, 2006 at 11:47:04AM -0700, Brian D. Carlstrom wrote:
> > > A quick grep memcpy in the recent glibc sources on my
> linux/ppc box
> > > seems to show no where near that level of optimization,
> but I admit
> > > that I could have missed something.
> >
> > http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
>
> Very interesting. According to that page, the memcpy
> optimizations seem to be using 64-bit operations and that
> 128-bit AltiVec operations are still being solicited.
"Still"?
http://www.freevec.org/
Been there for months, before the glibc thing. Most of the functions
are ready. Anyone can bugfix this. The beauty of GPL. The ugly part
is.. we've had this there for months. Nobody has contributed a single
update or bugfix or even a performance test as far as I know.
> However, I'm guessing this addon is not something found in
> common distributions for PowerPC like Debian, Fedora, Gentoo,
> Ubuntu, ...
Indeed it's a cute feature but we were scared away by the glibc guys
when it came to glibc-ports (perhaps they just considered it not
ready, but we wanted it in there for the first release, which was
the next one). Hence freevec. Konstantinos will get back in a couple
weeks and post some updates.
The more interesting code is the MySQL stuff. All of this has been
developed by finding good examples of apps, profiling them and then
optimizing the top few functions that are most used.
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
From: Arun Kumar @ 2006-07-21 14:56 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 15658 bytes --]
Hi ,
Can anyone help me in this naive problem ?
I am using k 2.4.x based on ppc8245 based .I have a 8MB flash mapped to
adress -0xff800000 .with 4 interleaved AMD flash devices each of size 2Mib .
Inte
The problem I am facing are two :
I am not sure whether my flash read/write routines are working properly
.(cfi_cmdset_0002.c routines )
I am able to detect my flash and do MTD partions too on the flash .But I
cannot see that in my
dev directory .I mean I should see something like /dev/mtd0 ...etc .
As I want to mount JFFS2 and I am not sure of whether i can mount any
Filesystem without seeing it in /dev directory .
Is there way wherein I can invoke mtd->write/mtd/->
read routines so that I can be sure that my CFI driver is working fine ?
these routines are mapped to amdstd_read/write routines in cfi_cmdset_0002
routine .
mtd->read = cfi_amdstd_read;
mtd->write = cfi_amdstd_write;
Here is my dump
################################################################
LSP Revision 1
Starting kswapd
Disabling the Out Of Memory Killer
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis
Communications
AB.
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI en
abled
ttyS00 at 0xfcf04500 (irq = 13) is a ST16650
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
AMD_FLASH_INIT called *aks *
physmap flash device: 800000 at ff800000 virtual address Number of erase
regions
: 4
Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
Primary Algorithm Table at 0040
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
No Vpp line
Typical byte/word write timeout: 128 µs
Maximum byte/word write timeout: 256 µs
Full buffer write not supported
Typical block erase timeout: 1024 ms
Maximum block erase timeout: 16384 ms
Chip erase not supported
Device size: 0x200000 bytes (2 MiB)
Flash Device Interface description: 0x0002
- supports x8 and x16 via BYTE# with asynchronous interface
Max. bytes in buffer write: 0x1
Number of Erase Block Regions: 4
Erase Region #0: BlockSize 0x4000 bytes, 1 blocks
Erase Region #1: BlockSize 0x2000 bytes, 2 blocks
Erase Region #2: BlockSize 0x8000 bytes, 1 blocks
Erase Region #3: BlockSize 0x10000 bytes, 31 blocks
Amd/Fujitsu Extended Query Table v1.3 at 0x0040
number of CFI chips: 4
in amdstd_setup 0:
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
in MTD Partitioning <5>No RedBoot partition table detected in
phys_mapped_flash
Using physmap partition definition
Creating 3 MTD partitions on "phys_mapped_flash":
0x00000000-0x00040000 : "foo-ets0"
mtd: Giving out device 0 to foo-ets0
0x00040000-0x001e0000 : "foo-ets1"
mtd: partition "agere-ets1" doesn't end on an erase block -- force read-only
mtd: Giving out device 1 to foo-ets1
0x001e0000-0x00200000 : "foo-ets2"
mtd: partition "foo-ets2" doesn't start on an erase block boundary -- force
re
ad-only
mtd: Giving out device 2 to foo-ets2
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
IP-Config: No network devices available.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
/dev/console mapped to mkdev 5: minor: 1
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1247k freed
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 76k init
calling sbin/init
init started: BusyBox v1.2.0 (2006.07.12-05:25+0000) multi-call binary
init started: BusyBox v1.2.0 (2006.07.12-05:25+0000) multi-call binary
Starting pid 8, console /dev/ttyS0: '/bin/ash'
/ $ cd /dev
/dev $ ls
console loop2 loop7 ram1 ram14 ram4 ram9 urandom
full loop3 mem ram10 ram15 ram5 random zero
kmem loop4 null ram11 ram16 ram6 tty
loop0 loop5 port ram12 ram2 ram7 tty0
loop1 loop6 ram0 ram13 ram3 ram8 ttyS0
################################################################
#
# Automatically generated make config: don't edit
#
# CONFIG_UID16 is not set
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_GENERIC_ISA_DMA=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_ADVANCED_OPTIONS is not set
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
#
# Platform support
#
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_6xx=y
# CONFIG_40x is not set
# CONFIG_440 is not set
# CONFIG_POWER3 is not set
# CONFIG_8xx is not set
# CONFIG_8260 is not set
CONFIG_PPC_STD_MMU=y
# CONFIG_EMBEDDED_OOM_KILLER is not set
# CONFIG_ALL_PPC is not set
# CONFIG_APUS is not set
# CONFIG_WILLOW is not set
# CONFIG_CPCI690 is not set
# CONFIG_PCORE is not set
# CONFIG_POWERPMC250 is not set
# CONFIG_PPMC260 is not set
# CONFIG_EV64260 is not set
# CONFIG_SPRUCE is not set
# CONFIG_MENF1 is not set
# CONFIG_PUMA_A is not set
# CONFIG_HXEB100 is not set
# CONFIG_LOPEC is not set
# CONFIG_MCPN765 is not set
# CONFIG_MVME5100 is not set
# CONFIG_PPLUS is not set
# CONFIG_PRPMC750 is not set
# CONFIG_PRPMC800 is not set
CONFIG_SANDPOINT=y
# CONFIG_POWERK2 is not set
# CONFIG_ADIR is not set
# CONFIG_K2 is not set
# CONFIG_PAL4 is not set
# CONFIG_GEMINI is not set
# CONFIG_ZX4500 is not set
# CONFIG_MPC10X_STORE_GATHERING is not set
# CONFIG_SANDPOINT_X3 is not set
# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set
# CONFIG_IKCONFIG is not set
# CONFIG_ALTIVEC is not set
# CONFIG_TAU is not set
CONFIG_PPC_ISATIMER=y
#
# General setup
#
CONFIG_MAX_POSIX_TIMERS=3000
# CONFIG_HIGH_RES_TIMERS is not set
# CONFIG_HIGHMEM is not set
# CONFIG_ILATENCY is not set
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
CONFIG_PCI=y
CONFIG_NET=y
CONFIG_SYSCTL=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SEMMNI=128
CONFIG_SYSVIPC_SEMMSL=250
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_MAX_USER_RT_PRIO=100
CONFIG_MAX_RT_PRIO=0
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_MULTITHREADED_CORES=y
CONFIG_KERNEL_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_PCI_NAMES is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
CONFIG_PPC_RTC=m
# CONFIG_CMDLINE_BOOL is not set
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=2
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CONCAT=y
CONFIG_MTD_REDBOOT_PARTS=y
CONFIG_MTD_CMDLINE_PARTS=y
#
# User Modules And Translation Layers
#
# CONFIG_MTD_CHAR is not set
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
# CONFIG_MTD_CFI_NOSWAP is not set
CONFIG_MTD_CFI_BE_BYTE_SWAP=y
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
# CONFIG_MTD_CFI_B1 is not set
CONFIG_MTD_CFI_B2=y
# CONFIG_MTD_CFI_B4 is not set
# CONFIG_MTD_CFI_B8 is not set
# CONFIG_MTD_CFI_I1 is not set
# CONFIG_MTD_CFI_I2 is not set
CONFIG_MTD_CFI_I4=y
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
# CONFIG_MTD_MOT_MVP is not set
# CONFIG_MTD_POWERPLUS is not set
# CONFIG_MTD_K2 is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_DOCPROBE is not set
#
# Serial Flash Device Drivers
#
# CONFIG_MTD_SFLASH is not set
#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set
#
# Plug and Play configuration
#
# CONFIG_PNP is not set
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_INITRD=y
# CONFIG_BLK_STATS is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Cryptography support (CryptoAPI)
#
# CONFIG_CRYPTO is not set
#
# 128 bit blocksize
#
#
# 64 bit blocksize
#
#
# Deprecated
#
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_FILTER is not set
# CONFIG_NET_NEIGH_DEBUG is not set
# CONFIG_NET_RESTRICTED_REUSE is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IPSEC is not set
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_IPV4_IPSEC_TUNNEL=y
#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
CONFIG_IPV6=m
# CONFIG_IPV6_DEBUG is not set
# CONFIG_IPV6_IM is not set
# CONFIG_IPV6_ZONE is not set
# CONFIG_IPV6_DROP_FAKE_V4MAPPED is not set
# CONFIG_IPV6_6TO4_NEXTHOP is not set
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ANYCAST is not set
# CONFIG_IPV6_ISATAP is not set
# CONFIG_IPV6_PREFIXLIST is not set
# CONFIG_IPV6_SUBTREES is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_MLD6_ALL_DONE is not set
# CONFIG_IPV6_NODEINFO is not set
#
# IPv6: Netfilter Configuration
#
# CONFIG_IP6_NF_QUEUE is not set
# CONFIG_IP6_NF_IPTABLES is not set
CONFIG_IPV6_IPSEC_TUNNEL=y
# CONFIG_IPV6_IPV6_TUNNEL is not set
# CONFIG_IPV6_MOBILITY is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
#
#
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# Appletalk devices
#
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
#
# ATA/IDE/MFM/RLL support
#
# CONFIG_IDE is not set
# CONFIG_BLK_DEV_IDE_MODES is not set
# CONFIG_BLK_DEV_HD is not set
#
# SCSI support
#
# CONFIG_SCSI is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set
#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Network device support
#
# CONFIG_NETDEVICES is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Console drivers
#
# CONFIG_VGA_CONSOLE is not set
#
# Frame-buffer support
#
# CONFIG_FB is not set
#
# Input core support
#
CONFIG_INPUT=m
CONFIG_INPUT_KEYBDEV=m
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=m
#
# Macintosh device drivers
#
#
# Character devices
#
# CONFIG_VT is not set
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_UNIX98_PTYS is not set
# CONFIG_HVC_CONSOLE is not set
# CONFIG_IXP2000_SLAVE is not set
#
# I2C support
#
# CONFIG_I2C is not set
#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_MOUSE is not set
#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_INPUT_SERIO is not set
#
# Joysticks
#
# CONFIG_QIC02_TAPE is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_LINUX_LED is not set
# CONFIG_AMD_PM768 is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# File systems
#
# CONFIG_QUOTA is not set
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
# CONFIG_REISERFS_FS is not set
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=m
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
# CONFIG_FAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=2
CONFIG_JFFS2_FS_NAND=y
# CONFIG_CRAMFS is not set
# CONFIG_POSIX_MQUEUE_FS is not set
# CONFIG_TMPFS is not set
CONFIG_RAMFS=y
# CONFIG_ISO9660_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_QNX4FS_FS is not set
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_XFS_FS is not set
# Network File Systems
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SUNRPC is not set
# CONFIG_LOCKD is not set
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
# CONFIG_ZISOFS_FS is not set
# Partition Types
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_SMB_NLS is not set
# CONFIG_NLS is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB is not set
#
# Bluetooth support
#
# CONFIG_BLUEZ is not set
#
# Kernel tracing
#
# CONFIG_TRACE is not set
#
# Library routines
#
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_SERIAL_TEXT_DEBUG is not set
################################################################
Can any happy soul let me know :--
1)How to mount jffs2 on this flash and also to test mtd->read/write routines
?
2) Is it ok not to see mtd0.. partions in /dev directory .
3 ) Where do I register the mtd partitions to get them noticed here ??
Thanks
Arun
[-- Attachment #2: Type: text/html, Size: 17893 bytes --]
^ permalink raw reply
* Re: AltiVec in the kernel
From: Linas Vepstas @ 2006-07-21 16:51 UTC (permalink / raw)
To: Matt Sealey
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <000001c6acd3$ea93f5c0$99dfdfdf@bakuhatsu.net>
On Fri, Jul 21, 2006 at 09:42:32AM -0500, Matt Sealey wrote:
>
> > > http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
> >
> > 128-bit AltiVec operations are still being solicited.
>
> "Still"?
>
> http://www.freevec.org/
>
> Been there for months, before the glibc thing. Most of the functions
> are ready. Anyone can bugfix this. The beauty of GPL. The ugly part
> is.. we've had this there for months. Nobody has contributed a single
> update or bugfix or even a performance test as far as I know.
Sounds like a problem of advertising and communications. This is
kind of "under the radar" for most users and developers. It needs to
work out-of-the-box, most people, even those with interest in
performance, will not even be aware of the possibility to tne this.
It should be folded into glibc. It is up to the altivec product vendor
to nag the glibc folks into folding it in. This task could be as hard
as writing the code in the first place.
> Indeed it's a cute feature but we were scared away by the glibc guys
Many maintainers of core libraries have similar behaviour patterns.
Besides glibc, gcc and gsl come to mind. This is becase they get tired out
by naive eager-beavers who walk in with the greatest idea in the world,
make a big fuss about it, and the proceed to demonstrate that they have
absolutely no clue of what they're talking about. For every ten of
those, there's maybe one legit idea. Worse, many of these "clueless
newbies" come in the surprising shape of PhD's working outside thier
specialty, and can convingingly sling jargon and authority for a while
before its realized they're just... clueless.
If you've got good code, you'll just need to be persistent.
--linas
^ permalink raw reply
* Re: mpic discovery on JS20
From: Benjamin Herrenschmidt @ 2006-07-21 17:37 UTC (permalink / raw)
To: Amos Waterland; +Cc: linuxppc-dev
In-Reply-To: <20060720231601.GA24736@kvasir.watson.ibm.com>
On Thu, 2006-07-20 at 19:16 -0400, Amos Waterland wrote:
> Current Linus and Paulus trees do this on JS20 blades with SLOF:
I need a tarball of /proc/device-tree on these.
> Failed to locate the MPIC interrupt controller
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> Maple: Found RTC at IO 0x1070
> cpu 0x0: Vector: 700 (Program Check) at [c00000007ef83ab0]
> pc: c00000000002e0c8: .mpic_request_ipis+0x34/0xc8
> lr: c00000000036b484: .smp_mpic_probe+0x3c/0x58
> sp: c00000007ef83d30
> msr: 9000000000029032
> current = 0xc00000000194d610
> paca = 0xc00000000038f180
> pid = 1, comm = swapper
> kernel BUG in mpic_request_ipis at arch/powerpc/sysdev/mpic.c:1132!
>
> Doing a git-bisect produces this:
>
> 0ebfff1491ef85d41ddf9c633834838be144f69f is first bad commit
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Mon Jul 3 21:36:01 2006 +1000
>
> [POWERPC] Add new interrupt mapping core and change platforms to use it
>
> This adds the new irq remapper core and removes the old one. Because
> there are some fundamental conflicts with the old code, like the value
> of NO_IRQ which I'm now setting to 0 (as per discussions with Linus),
> etc..., this commit also changes the relevant platform and driver code
> over to use the new remapper (so as not to cause difficulties later
> in bisecting).
>
> This patch removes the old pre-parsing of the open firmware interrupt
> tree along with all the bogus assumptions it made to try to renumber
> interrupts according to the platform. This is all to be handled by the
> new code now.
>
> For the pSeries XICS interrupt controller, a single remapper host is
> created for the whole machine regardless of how many interrupt
> presentation and source controllers are found, and it's set to match
> any device node that isn't a 8259. That works fine on pSeries and
> avoids having to deal with some of the complexities of split source
> controllers vs. presentation controllers in the pSeries device trees.
>
> The powerpc i8259 PIC driver now always requests the legacy interrupt
> range. It also has the feature of being able to match any device node
> (including NULL) if passed no device node as an input. That will help
> porting over platforms with broken device-trees like Pegasos who don't
> have a proper interrupt tree.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: AltiVec in the kernel
From: Matt Sealey @ 2006-07-21 18:08 UTC (permalink / raw)
To: 'Linas Vepstas'
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <20060721165130.GS5905@austin.ibm.com>
> Sounds like a problem of advertising and communications.
> This is kind of "under the radar" for most users and
> developers. It needs to work out-of-the-box, most people,
> even those with interest in performance, will not even be
> aware of the possibility to tne this.
It's listed on every site we have, and on PenguinPPC.org too if I
recall (hi Hollis) it even got a sticky news item like a lot of the
stuff we do (thanks Hollis :).
Everyone who cares knows about it, I would think. Probably not
enough people care, is the problem.
> It should be folded into glibc. It is up to the altivec
> product vendor to nag the glibc folks into folding it in.
You mean Freescale? Or Genesi?
Freevec was being developed as a "perfect opportunity". glibc-ports
came to life and was something that code could be contributed to.
Since it was such a hassle dealing with the glibc guys, it ended up
being a seperate library for now.
> This task could be as hard as writing the code in the first place.
I think we could handle it if there were less stubborn mules maintaining
the most important software. I can think of one guy in particular.. but
I won't name him.
> Many maintainers of core libraries have similar behaviour patterns.
> Besides glibc, gcc and gsl come to mind. This is becase they
> get tired out by naive eager-beavers who walk in with the
> greatest idea in the world
I think this kind of behaviour stalls Open Source software,
because it unfairly treats those *with* clues.
<-us-> do you want the AltiVec code or not?
<them> Oh no because I am bored of dealing with people who only had ideas!!
It doesn't make much sense politically or technically.
So like I said we could have had this code in glibc when glibc-ports
first was conceptualised and then released, but there was just too
many mules in the way.
Check the freevec.org whitepapers section), Konstantinos is not just
"ideas", he proved out optimizations and then implemented them.
Is it his fault that they're not in glibc, because he's "stupid" or
"clueless"? :D
> If you've got good code, you'll just need to be persistent.
Personally I am pretty tired (in return) with angry-faced Open
Source developers deciding that "Open Source" is equivalent to
"My Source, Back Off, Your Patch Sucks". It is always the choice
of the lead developer (and/or copyright holder) to refuse
patches, but.. seriously.. a lot of Open Source development is
the wrong kind of dictatorship.
Cynicism aside.. :D
</rant>
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* Re: problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
From: Ben Warren @ 2006-07-21 16:20 UTC (permalink / raw)
To: Arun Kumar; +Cc: linuxppc-embedded
In-Reply-To: <edd12c050607210756h71bab7f8ve323edf3bf6077c6@mail.gmail.com>
Hi Arun,
On Fri, 2006-07-21 at 20:26 +0530, Arun Kumar wrote:
> Hi ,
> Can anyone help me in this naive problem ?
>
Then a naive answer is most fitting... Turns out that's my specialty.
> #
> # Memory Technology Devices (MTD)
> #
> CONFIG_MTD=y
> CONFIG_MTD_DEBUG=y
> CONFIG_MTD_DEBUG_VERBOSE=2
> CONFIG_MTD_PARTITIONS=y
> CONFIG_MTD_CONCAT=y
> CONFIG_MTD_REDBOOT_PARTS=y
> CONFIG_MTD_CMDLINE_PARTS=y
Probably get rid of REDBOOT if you're not using that bootloader
>
> #
> # User Modules And Translation Layers
> #
> # CONFIG_MTD_CHAR is not set
> # CONFIG_MTD_BLOCK is not set
> # CONFIG_MTD_BLOCK_RO is not set
> # CONFIG_FTL is not set
> # CONFIG_NFTL is not set
> # CONFIG_INFTL is not set
>
You need to enable MTD_CHAR to read/write and MTD_BLOCK to mount
> Can any happy soul let me know :--
>
> 1)How to mount jffs2 on this flash and also to test mtd->read/write
> routines ?
Start with the char drivers (/dev/mtd0 etc.). You'll need one for each
partition you want to experiment with.
How about creating the nodes manually?
mknod /dev/mtd0 c 90 0
mknod /dev/mtd1 c 90 2 etc. (minor # increments in 2s)
Add a block device for each partition:
mknod /dev/mtdblock0 b 31 0
mknod /dev/mtdblock1 b 31 1 etc.
Once you clean up #3 below, you should be able to read/write the char
devices using commands like 'cat', or write a simple user-space app
using "open, read, write", etc if you'd rather look at the actual binary
data.
You can then experiment with mounting the JFFS2. I recommend booting to
an NFS file system then mounting the JFFS2 with something like:
mount -t jffs2 /dev/mtdblock5 /mnt/temp (Use the correct partition)
>
> 2) Is it ok not to see mtd0.. partions in /dev directory .
Pretty sure you'll need these
>
> 3 ) Where do I register the mtd partitions to get them noticed
> here ??
Looks like your partitions are already being found, but are probably not
set up right. I don't know if this is a static definition in your board
init code or passed by command line from the bootloader, but it looks
like the values don't line up with your device:
*********
Using physmap partition definition
Creating 3 MTD partitions on "phys_mapped_flash":
0x00000000-0x00040000 : "foo-ets0"
mtd: Giving out device 0 to foo-ets0
0x00040000-0x001e0000 : "foo-ets1"
mtd: partition "agere-ets1" doesn't end on an erase block -- force
read-only
mtd: Giving out device 1 to foo-ets1
0x001e0000-0x00200000 : "foo-ets2"
mtd: partition "foo-ets2" doesn't start on an erase block boundary --
force read-only
*********
--------------------------------------------------------------------------
Hopefully this helps you proceed a little bit.
regards,
Ben
^ permalink raw reply
* Re: AltiVec in the kernel
From: Brian D. Carlstrom @ 2006-07-21 18:46 UTC (permalink / raw)
To: Linas Vepstas
Cc: 'Olof Johansson', 'Paul Mackerras',
'linuxppc-dev list'
In-Reply-To: <20060721165130.GS5905@austin.ibm.com>
At Fri, 21 Jul 2006 11:51:30 -0500,
Linas Vepstas wrote:
> If you've got good code, you'll just need to be persistent.
While I agree with most of Matt's rant, I think Linas is right as well.
Hearing that code is already in a distribution like Gentoo makes it
easier to make the case that the code doesn't suck or is vaporware.
-bri
disclaimer: a PhD student working outside my specialty :)
^ permalink raw reply
* Boot problem on Sandpoint
From: Benoit Lajoie-Dorval @ 2006-07-21 18:49 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
Hi all,
I have to port Linux on a Sandpoint Board wtih a MPC8241 processor on. I
built a kernel using linux 2.6.15 and create an zImage.initrd.elf with a
ramdisk. All of this (linux and ramdisk) was packaged with ELDK 4.0. I also
minimized everything in the .config file to only have what is really
necessary (serial port, 6xx processor, etc). The communication is made with
the board by its internal serial port and Dink32 is used to do everything
else.
The problem is that when I execute the loaded zImage.initrd.elf, the boot
sequence just hangs there and I just don't see anything happening. There is
nothing that is displayed. I know that the elf file as an offset header of
0X10000, so the problem is not there. I also put some breakpoints and trace
using Dink32 to see where it stops and it may have something to do with the
disable_6xx_mmu in the utils.S file.
I just really don't know what's wrong in my config and I hope someone could
help me on this.
Thank you
Benoit Lajoie-Dorval
^ permalink raw reply
* Re: Boot problem on Sandpoint
From: Mark A. Greer @ 2006-07-21 19:58 UTC (permalink / raw)
To: Benoit Lajoie-Dorval; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <D3A60B685BD79544ACA481B73FA81EA02F4F27@COBALT>
On Fri, Jul 21, 2006 at 11:49:14AM -0700, Benoit Lajoie-Dorval wrote:
> Hi all,
> I have to port Linux on a Sandpoint Board wtih a MPC8241 processor on.
Tell your boss that it'll take 3 months including lots of overtime,
then crack open a beer! The sandpoint/8241 has been working for years.
> built a kernel using linux 2.6.15 and create an zImage.initrd.elf with a
> ramdisk. All of this (linux and ramdisk) was packaged with ELDK 4.0. I also
> minimized everything in the .config file to only have what is really
> necessary (serial port, 6xx processor, etc). The communication is made with
> the board by its internal serial port and Dink32 is used to do everything
> else.
>
> The problem is that when I execute the loaded zImage.initrd.elf, the boot
> sequence just hangs there and I just don't see anything happening. There is
> nothing that is displayed. I know that the elf file as an offset header of
> 0X10000, so the problem is not there. I also put some breakpoints and trace
> using Dink32 to see where it stops and it may have something to do with the
> disable_6xx_mmu in the utils.S file.
>
> I just really don't know what's wrong in my config and I hope someone could
> help me on this.
Well, you did lots of things that could have broken it. Go back to
square one: default .config with nfs mounted rootfs. Get that to work
then tune the .config and add a ramdisk.
Also, if you have a bdi2000 or some other jtag/cops debugger, you can
dump __log_buf and see if there is anything there.
Mark
^ permalink raw reply
* stupid linker question....
From: Steve Iribarne (GMail) @ 2006-07-21 20:06 UTC (permalink / raw)
To: linuxppc-embedded
I forgot the flag that generates a list file that has both assembly
and c mixed in.
Anyone?
Thanks...
-stv
^ permalink raw reply
* Re: stupid linker question....
From: Wade Maxfield @ 2006-07-21 21:10 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690607211306rea34437gb05e84d24e8c66a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
gcc -Wa,-alhs -g main.c >main.cs
will put interleaved code/assembly into main.cs file.
wade
On 7/21/06, Steve Iribarne (GMail) <netstv@gmail.com> wrote:
>
> I forgot the flag that generates a list file that has both assembly
> and c mixed in.
>
> Anyone?
>
> Thanks...
>
> -stv
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 898 bytes --]
^ permalink raw reply
* Re: AltiVec in the kernel
From: Hollis Blanchard @ 2006-07-21 21:30 UTC (permalink / raw)
To: Linas Vepstas, Matt Sealey
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras', Konstantinos Margaritis
In-Reply-To: <20060721165130.GS5905@austin.ibm.com>
On Fri, 21 Jul 2006 11:51:30 -0500, "Linas Vepstas"
<linas@austin.ibm.com> said:
> On Fri, Jul 21, 2006 at 09:42:32AM -0500, Matt Sealey wrote:
> > http://www.freevec.org/
> >
> > Been there for months, before the glibc thing. Most of the functions
> > are ready. Anyone can bugfix this. The beauty of GPL. The ugly part
> > is.. we've had this there for months. Nobody has contributed a single
> > update or bugfix or even a performance test as far as I know.
>
> Sounds like a problem of advertising and communications. This is
> kind of "under the radar" for most users and developers. It needs to
> work out-of-the-box, most people, even those with interest in
> performance, will not even be aware of the possibility to tne this.
It is difficult to make sure every OSS developer is notified of all work
they may be interested in...
However, I have noticed a trend where Genesi people seem to think
everybody pays attention to their websites (and the same could be said
for Debian and other subcultures). In this case there actually have been
other people aware of this project, but not very many. Considering all
the traffic about it on ppczone.org, people looking for exposure for
their project may want to look beyond PPCZone.
> It should be folded into glibc. It is up to the altivec product vendor
> to nag the glibc folks into folding it in. This task could be as hard
> as writing the code in the first place.
Konstantinos is aware of Steve's glibc project and has indicated he'll
try to contribute to it.
To be fair, probably not many people have heard of Steve's project
either. I doubt Konstantinos would have heard of it if I hadn't
mentioned it.
-Hollis
^ permalink raw reply
* Re: AltiVec in the kernel
From: Peter Bergner @ 2006-07-21 22:21 UTC (permalink / raw)
To: Brian D. Carlstrom
Cc: Olof Johansson, 'linuxppc-dev list',
'Paul Mackerras', Steve Munroe
In-Reply-To: <lezmf4j5ym.wl%bdc@carlstrom.com>
On Thu, 2006-07-20 at 14:56 -0700, Brian D. Carlstrom wrote:
> At Thu, 20 Jul 2006 14:05:23 -0500, Olof Johansson wrote:
> > http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
>
> Very interesting. According to that page, the memcpy optimizations seem
> to be using 64-bit operations and that 128-bit AltiVec operations are
> still being solicited.
>
> I was encouraged to see the following:
>
> If you need to build generic distributions (supporting several
> <cpu_types>) you can leverage the dl_procinfo support built into
> glibc. This mechanism allows for multiple versions of the core
> libraries (libc, libm, librt, libpthread, libpthread_db) to be
> stored in hardware/platform specific subdirectories under /lib[64].
Actually, this support is not limited to the core glibc routines or
the system lib directors /lib/ and /usr/lib/. This works just as well
for third party shipped libraries in their own library trees as the
following example (on a power5 box) shows:
bergner@vervainp1:~/cpu-tuned-libs> pwd
/home/bergner/cpu-tuned-libs
bergner@vervainp1:~/cpu-tuned-libs> ls lib/ lib/power5/
lib/:
libfoo.so power5/
lib/power5/:
libfoo.so
bergner@vervainp1:~/cpu-tuned-libs> gcc
-L/home/bergner/cpu-tuned-libs/lib -R/home/bergner/cpu-tuned-libs/lib
main.c -lfoo
bergner@vervainp1:~/cpu-tuned-libs> ldd a.out
linux-vdso32.so.1 => (0x00100000)
libfoo.so => /home/bergner/cpu-tuned-libs/lib/power5/libfoo.so
(0x0ffde000)
libc.so.6 => /lib/power5/libc.so.6 (0x0fe69000)
/lib/ld.so.1 (0xf7fe1000)
bergner@vervainp1:~/cpu-tuned-libs> ./a.out
Loaded the optimzed lib
bergner@vervainp1:~/cpu-tuned-libs> rm lib/power5/libfoo.so
bergner@vervainp1:~/cpu-tuned-libs> ldd a.out
linux-vdso32.so.1 => (0x00100000)
libfoo.so => /home/bergner/cpu-tuned-libs/lib/libfoo.so
(0x0ffde000)
libc.so.6 => /lib/power5/libc.so.6 (0x0fe69000)
/lib/ld.so.1 (0xf7fe1000)
bergner@vervainp1:~/cpu-tuned-libs> ./a.out
Loaded the unoptimzed lib
The runtime loader magic uses the AT_PLATFORM string value as
the subdirectory to search in under the .../lib/ or .../lib64/
library directory. To find out what your AT_PLATFORM value is
on your current box, you can do:
bergner@vervainp1:~/cpu-tuned-libs> LD_SHOW_AUXV=1 /bin/true
AT_DCACHEBSIZE: 0x80
AT_ICACHEBSIZE: 0x80
AT_UCACHEBSIZE: 0x0
AT_SYSINFO_EHDR: 0x100000
AT_HWCAP: power5 mmu fpu ppc64 ppc32
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x10000034
AT_PHENT: 32
AT_PHNUM: 9
AT_BASE: 0xf7fe1000
AT_FLAGS: 0x0
AT_ENTRY: 0x10000980
AT_UID: 1001
AT_EUID: 1001
AT_GID: 100
AT_EGID: 100
AT_SECURE: 0
AT_PLATFORM: power5
> However, I'm guessing this addon is not something found in common
> distributions for PowerPC like Debian, Fedora, Gentoo, Ubuntu, ...
At last years GCC Developers Summit, one of the Ubuntu guys mentioned
he was interested in adding it to Ubuntu. I haven't heard whether that
has shown up yet though. It will be available in upcoming SUSE and
Red Hat enterprise distros. I don't know about the others. As Olof
mentioned, it can take some lead time for this to get picked up.
There's also the question of how many and which processors a distro
will ship cpu optimized libraries for. Given all of the PowerPC
variants, they obviously can ship optimized libs for everything.
Peter
^ permalink raw reply
* Re: AltiVec in the kernel
From: Segher Boessenkool @ 2006-07-22 3:09 UTC (permalink / raw)
To: matt
Cc: 'Olof Johansson', 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <002b01c6acf0$a7417050$99dfdfdf@bakuhatsu.net>
> Freevec was being developed as a "perfect opportunity". glibc-ports
> came to life and was something that code could be contributed to.
> Since it was such a hassle dealing with the glibc guys, it ended up
> being a seperate library for now.
Do you have a pointer to an archive of that email thread? I can't
remember it.
You could give Freevec a whole lot more exposure, to people who
might be more interested in it than the average glibc user, by
putting it into uClibc first. Additional advantage is that you
don't have to care about forward/backward compatibility issues,
or even whether the platform a binary ends up running on actually
has AltiVec or not (uClibc gets tailored to the exact system it
runs on at compile time). So you can focus on the routines you
want to speed up instead of on all the infrastructure stuff
required for glibc.
You'll have to update uClibc's PowerPC port first though (mostly
just copying stuff from recent glibc) -- it seems the libc AltiVec
support (for handling setjmp() etc.) isn't in there yet.
>> This task could be as hard as writing the code in the first place.
Not as hard. Way, way harder instead. Part of that is that the
code probably really isn't good enough yet, sorry. And then there's
all the compatibility stuff, and symbol versioning, etc. And the
communication issue, of course.
Segher
^ permalink raw reply
* Reg. virtual address space in embedded linux
From: jagannathanjay @ 2006-07-22 5:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 958 bytes --]
Hi all
We are porting third party driver code from vxworks to Embedded linux in MPC 8260 under a evaluation platform from Embedded Planet in linux kernel space.
The first step we carried out was reading the chip id and we were able to read the chip id correctly. For reading the chip id we used the routine ChipReadMemory in the attached text and we were able to retrive the chip id successfully. Subsequently when we write and read from Chip Specific Control Status registers ,it didn't work. I checked the manual and the Chip Specific Control Status registers have RW access. Any inputs on how to check if the write we made to virtual address succeeds? Is there a way to dump the linux virtual address and examine the write we made ?
Regards
Jay
________________________________________________________________________
Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection.
[-- Attachment #1.2: Type: text/html, Size: 2129 bytes --]
[-- Attachment #2: RWroutines.txt --]
[-- Type: text/plain, Size: 831 bytes --]
int ChipReadMemory(unsigned int arg_phys_addr,unsigned int *memValue)
{
void *virt_addr = NULL;
unsigned int phys_addr = 0;
phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
virt_addr = ioremap(phys_addr, 4);
if(virt_addr == NULL)
{
printk("ChipReadMemory: unable to perform ioremap \n");
return -1;
}
*memValue = readl(virt_addr);
iounmap(virt_addr);
return 0;
}
int ChipWriteMemory(unsigned int arg_phys_addr, unsigned int arg_val)
{
void *virt_addr = NULL;
unsigned int phys_addr = 0;
phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
virt_addr = ioremap(phys_addr, 4);
if(virt_addr == NULL)
{
printk("ChipWriteMemory : unable to perform ioremap \n");
return -1;
}
writel(arg_val,virt_addr);
iounmap(virt_addr);
return 0;
}
^ permalink raw reply
* linux kernel hang in execve("/sbin/init")
From: Eric Nuckols @ 2006-07-22 6:10 UTC (permalink / raw)
To: linuxppc-embedded
I googled...and googled...etc. etc.. when trying to solve the problem of my
linux kernel seemingly locking or hanging when it gets to the last part of
the linux init in main.c
I saw lots of information and suggestions related to try /bin/sh or make
sure your initrd is ok or make sure you have more than one session..etc.
etc... .. and all of these topics were mostly from 2001-2003...well..
2006...it's here and apparently some of us haven't gotten smarter..
I had this problem recently where my kernel would boot and freeze or hang in
execve of /sbin/init and also of /bin/sh or /bin/bash...
I debugged and debugged.. and finally thougt... why not try the default
Kernel config for my target, the PrPmc800 from Motorola... and see what that
does.. Originally, I started with the MontaVista 3.1 Pro setup for the
board and it works...so I used it's Kernel .config file to configure my
latest and greatest (at the time) 2.6.16.18 kernel thinking... well.. this
has to work..
so.. I ended up with a kernel that semingly hang/froze/locked on the execve
call in the linux init routines...
guess what folks... the google searches left me just on the verge of giving
up.
I am here to post this info as somewhat of another answer/alternative to
people in the same predicament...
if you are having problems with your cross-compiled / embedded ppc kernel
freezing or hanging on execve, try using the default configuration for your
target when you build the kernel...
in my case, I did this sort of thing and all of a sudden, my kernel was
working:
cd to kernel dir
make distclean
make CROSS_COMPILE=powerpc-7400-linux-gnu- prpmc800_defconfig
make zImage.initrd
etc..etc..
it turns out that since I was basing my initial config off of the 2.4.x
.config from MontaVista, my kernel didn't boot as desired...
so I figured.. after all the googling and working on it that the default
PrPmc800 config had to boot... why else call it the default config..
so that's my story.. since then, I have copied the kernel
dir/arch/ppc/configs/prpmc800_defconfig to a temporary file, and modified it
as necessary...
moral of the story... if you are cross-compiling and having problems where
you hang on execve("/sbin/init") or execve("/bin/sh") or
execve("/bin/bash")..etc... try what I did before you go crazy analyzing
the initrd or the various /etc/ file configurations or any of the other
typical bs...
^ 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