* [PATCH 0/2] Cell xmon helpers
From: Michael Ellerman @ 2006-10-12 12:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cbe-oss-dev
The following two patches add three commands to xmon for stopping,
restarting and dumping info about spus from xmon.
For the folks on linuxppc-dev, these patches depend on another patch
which isn't in the powerpc tree yet AFAIK, you can get it here:
http://kernel.org/pub/linux/kernel/people/arnd/patches/2.6.17-arnd8/broken-out/spu-add-attributes.diff
cheers
^ permalink raw reply
* [PATCH 1/2] Add support for stopping spus from xmon
From: Michael Ellerman @ 2006-10-12 12:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <1160654587.449977.520618728447.qpush@concordia>
This patch adds support for stopping, and restarting, spus
from xmon. We use the spu master runcntl bit to stop execution,
this is apparently the "right" way to control spu execution and
spufs will be changed in the future to use this bit.
Testing has shown that to restart execution we have to turn the
master runcntl bit on and also rewrite the spu runcntl bit, even
if it is already set to 1 (running).
Stopping spus is triggered by the xmon command 'ss' - "spus stop"
perhaps. Restarting them is triggered via 'sr'. Restart doesn't
start execution on spus unless they were running prior to being
stopped by xmon.
Walking the spu->full_list in xmon after a panic, would mean
corruption of any spu struct would make all the others
inaccessible. To avoid this, and also to make the next patch
easier, we cache pointers to all spus during boot.
We attempt to catch and recover from errors while stopping and
restarting the spus, but as with most xmon functionality there are
no guarantees that performing these operations won't crash xmon
itself.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/spu_base.c | 4
arch/powerpc/xmon/xmon.c | 142 ++++++++++++++++++++++++++++++++-
include/asm-powerpc/xmon.h | 2
3 files changed, 146 insertions(+), 2 deletions(-)
Index: to-merge/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/cell/spu_base.c
+++ to-merge/arch/powerpc/platforms/cell/spu_base.c
@@ -38,6 +38,7 @@
#include <asm/spu.h>
#include <asm/spu_priv1.h>
#include <asm/mmu_context.h>
+#include <asm/xmon.h>
#include "interrupt.h"
@@ -914,6 +915,9 @@ static int __init init_spu_base(void)
break;
}
}
+
+ xmon_register_spus(&spu_full_list);
+
return ret;
}
module_init(init_spu_base);
Index: to-merge/arch/powerpc/xmon/xmon.c
===================================================================
--- to-merge.orig/arch/powerpc/xmon/xmon.c
+++ to-merge/arch/powerpc/xmon/xmon.c
@@ -35,6 +35,8 @@
#include <asm/rtas.h>
#include <asm/sstep.h>
#include <asm/bug.h>
+#include <asm/spu.h>
+#include <asm/spu_priv1.h>
#ifdef CONFIG_PPC64
#include <asm/hvcall.h>
@@ -145,6 +147,8 @@ static void xmon_print_symbol(unsigned l
const char *after);
static const char *getvecname(unsigned long vec);
+static int do_spu_cmd(void);
+
int xmon_no_auto_backtrace;
extern int print_insn_powerpc(unsigned long, unsigned long, int);
@@ -207,8 +211,12 @@ Commands:\n\
mi show information about memory allocation\n\
p call a procedure\n\
r print registers\n\
- s single step\n\
- S print special registers\n\
+ s single step\n"
+#ifdef CONFIG_PPC_CELL
+" ss stop execution on all spus\n\
+ sr restore execution on stopped spus\n"
+#endif
+" S print special registers\n\
t print backtrace\n\
x exit monitor and recover\n\
X exit monitor and dont recover\n"
@@ -516,6 +524,7 @@ int xmon(struct pt_regs *excp)
xmon_save_regs(®s);
excp = ®s;
}
+
return xmon_core(excp, 0);
}
EXPORT_SYMBOL(xmon);
@@ -808,6 +817,8 @@ cmds(struct pt_regs *excp)
cacheflush();
break;
case 's':
+ if (do_spu_cmd() == 0)
+ break;
if (do_step(excp))
return cmd;
break;
@@ -2630,3 +2641,130 @@ void __init xmon_setup(void)
if (xmon_early)
debugger(NULL);
}
+
+#ifdef CONFIG_PPC_CELL
+
+struct spu_info {
+ struct spu *spu;
+ u64 saved_mfc_sr1_RW;
+ u32 saved_spu_runcntl_RW;
+ u8 stopped_ok;
+};
+
+#define XMON_NUM_SPUS 16 /* Enough for current hardware */
+
+static struct spu_info spu_info[XMON_NUM_SPUS];
+
+void xmon_register_spus(struct list_head *list)
+{
+ struct spu *spu;
+
+ list_for_each_entry(spu, list, full_list) {
+ if (spu->number >= XMON_NUM_SPUS) {
+ WARN_ON(1);
+ continue;
+ }
+
+ spu_info[spu->number].spu = spu;
+ spu_info[spu->number].stopped_ok = 0;
+ }
+}
+
+static void stop_spus(void)
+{
+ struct spu *spu;
+ int i;
+ u64 tmp;
+
+ for (i = 0; i < XMON_NUM_SPUS; i++) {
+ if (!spu_info[i].spu)
+ continue;
+
+ if (setjmp(bus_error_jmp) == 0) {
+ catch_memory_errors = 1;
+ sync();
+
+ spu = spu_info[i].spu;
+
+ spu_info[i].saved_spu_runcntl_RW =
+ in_be32(&spu->problem->spu_runcntl_RW);
+
+ tmp = spu_mfc_sr1_get(spu);
+ spu_info[i].saved_mfc_sr1_RW = tmp;
+
+ tmp &= ~MFC_STATE1_MASTER_RUN_CONTROL_MASK;
+ spu_mfc_sr1_set(spu, tmp);
+
+ sync();
+ __delay(200);
+
+ spu_info[i].stopped_ok = 1;
+ printf("Stopped spu %.2d\n", i);
+ } else {
+ catch_memory_errors = 0;
+ printf("*** Error stopping spu %.2d\n", i);
+ }
+ catch_memory_errors = 0;
+ }
+}
+
+static void restart_spus(void)
+{
+ struct spu *spu;
+ int i;
+
+ for (i = 0; i < XMON_NUM_SPUS; i++) {
+ if (!spu_info[i].spu)
+ continue;
+
+ if (!spu_info[i].stopped_ok) {
+ printf("*** Error, spu %d was not successfully stopped"
+ ", not restarting\n", i);
+ continue;
+ }
+
+ if (setjmp(bus_error_jmp) == 0) {
+ catch_memory_errors = 1;
+ sync();
+
+ spu = spu_info[i].spu;
+ spu_mfc_sr1_set(spu, spu_info[i].saved_mfc_sr1_RW);
+ out_be32(&spu->problem->spu_runcntl_RW,
+ spu_info[i].saved_spu_runcntl_RW);
+
+ sync();
+ __delay(200);
+
+ printf("Restarted spu %.2d\n", i);
+ } else {
+ catch_memory_errors = 0;
+ printf("*** Error restarting spu %.2d\n", i);
+ }
+ catch_memory_errors = 0;
+ }
+}
+
+static int do_spu_cmd(void)
+{
+ int cmd;
+
+ cmd = inchar();
+ switch (cmd) {
+ case 's':
+ stop_spus();
+ break;
+ case 'r':
+ restart_spus();
+ break;
+ default:
+ return -1;
+ }
+
+ return 0;
+}
+#else /* ! CONFIG_PPC_CELL */
+static int do_spu_cmd(void)
+{
+ return -1;
+}
+#endif
Index: to-merge/include/asm-powerpc/xmon.h
===================================================================
--- to-merge.orig/include/asm-powerpc/xmon.h
+++ to-merge/include/asm-powerpc/xmon.h
@@ -14,8 +14,10 @@
#ifdef CONFIG_XMON
extern void xmon_setup(void);
+extern void xmon_register_spus(struct list_head *list);
#else
static inline void xmon_setup(void) { };
+static inline void xmon_register_spus(struct list_head *list) { };
#endif
#endif /* __KERNEL __ */
^ permalink raw reply
* [PATCH 2/2] Add support for dumping spu info from xmon
From: Michael Ellerman @ 2006-10-12 12:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <1160654587.449977.520618728447.qpush@concordia>
This patch adds a command to xmon for dumping information about
spu structs. The command is 'sf' for "spu fields" perhaps, and
takes the spu number as an argument. This is the same value as the
spu->number field, or the "phys-id" value of a context when it is
bound to a physical spu.
We try to catch memory errors as we dump each field, hopefully this
will make the command reasonably robust, but YMMV. If people see a
need we can easily add more fields to the dump in future.
Output looks something like this:
0:mon> sf 0
Dumping spu fields at address c00000001ffd9e80:
number = 0x0
name = spe
devnode->full_name = /cpus/PowerPC,BE@0/spes/spe@0
nid = 0x0
local_store_phys = 0x20000000000
local_store = 0xd0000800801e0000
ls_size = 0x0
isrc = 0x4
node = 0x0
flags = 0x0
dar = 0x0
dsisr = 0x0
class_0_pending = 0
irqs[0] = 0x16
irqs[1] = 0x17
irqs[2] = 0x24
slb_replace = 0x0
pid = 0
prio = 0
mm = 0x0000000000000000
ctx = 0x0000000000000000
rq = 0x0000000000000000
timestamp = 0x0000000000000000
problem_phys = 0x20000040000
problem = 0xd000080080220000
problem->spu_runcntl_RW = 0x0
problem->spu_status_R = 0x0
problem->spu_npc_RW = 0x0
priv1 = 0xd000080080240000
priv1->mfc_sr1_RW = 0x33
priv2 = 0xd000080080250000
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/xmon/xmon.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 67 insertions(+), 1 deletion(-)
Index: to-merge/arch/powerpc/xmon/xmon.c
===================================================================
--- to-merge.orig/arch/powerpc/xmon/xmon.c
+++ to-merge/arch/powerpc/xmon/xmon.c
@@ -214,7 +214,8 @@ Commands:\n\
s single step\n"
#ifdef CONFIG_PPC_CELL
" ss stop execution on all spus\n\
- sr restore execution on stopped spus\n"
+ sr restore execution on stopped spus\n\
+ sf # dump spu fields for spu # (in hex)\n"
#endif
" S print special registers\n\
t print backtrace\n\
@@ -2744,8 +2745,67 @@ static void restart_spus(void)
}
}
+#define DUMP_WIDTH 23
+#define DUMP_FIELD(obj, format, field) \
+do { \
+ if (setjmp(bus_error_jmp) == 0) { \
+ catch_memory_errors = 1; \
+ sync(); \
+ printf(" %-*s = "format"\n", DUMP_WIDTH, \
+ #field, obj->field); \
+ sync(); \
+ __delay(200); \
+ } else { \
+ catch_memory_errors = 0; \
+ printf(" %-*s = *** Error reading field.\n", \
+ DUMP_WIDTH, #field); \
+ } \
+ catch_memory_errors = 0; \
+} while (0)
+
+static void dump_spu_fields(struct spu *spu)
+{
+ printf("Dumping spu fields at address %p:\n", spu);
+
+ DUMP_FIELD(spu, "0x%x", number);
+ DUMP_FIELD(spu, "%s", name);
+ DUMP_FIELD(spu, "%s", devnode->full_name);
+ DUMP_FIELD(spu, "0x%x", nid);
+ DUMP_FIELD(spu, "0x%lx", local_store_phys);
+ DUMP_FIELD(spu, "0x%p", local_store);
+ DUMP_FIELD(spu, "0x%lx", ls_size);
+ DUMP_FIELD(spu, "0x%x", isrc);
+ DUMP_FIELD(spu, "0x%x", node);
+ DUMP_FIELD(spu, "0x%lx", flags);
+ DUMP_FIELD(spu, "0x%lx", dar);
+ DUMP_FIELD(spu, "0x%lx", dsisr);
+ DUMP_FIELD(spu, "%d", class_0_pending);
+ DUMP_FIELD(spu, "0x%lx", irqs[0]);
+ DUMP_FIELD(spu, "0x%lx", irqs[1]);
+ DUMP_FIELD(spu, "0x%lx", irqs[2]);
+ DUMP_FIELD(spu, "0x%x", slb_replace);
+ DUMP_FIELD(spu, "%d", pid);
+ DUMP_FIELD(spu, "%d", prio);
+ DUMP_FIELD(spu, "0x%p", mm);
+ DUMP_FIELD(spu, "0x%p", ctx);
+ DUMP_FIELD(spu, "0x%p", rq);
+ DUMP_FIELD(spu, "0x%p", timestamp);
+ DUMP_FIELD(spu, "0x%lx", problem_phys);
+ DUMP_FIELD(spu, "0x%p", problem);
+ DUMP_FIELD(spu, "0x%x", problem->spu_runcntl_RW);
+ DUMP_FIELD(spu, "0x%x", problem->spu_status_R);
+ DUMP_FIELD(spu, "0x%x", problem->spu_npc_RW);
+ DUMP_FIELD(spu, "0x%p", priv1);
+
+ if (spu->priv1)
+ DUMP_FIELD(spu, "0x%lx", priv1->mfc_sr1_RW);
+
+ DUMP_FIELD(spu, "0x%p", priv2);
+}
+
static int do_spu_cmd(void)
{
+ unsigned long num = 0;
int cmd;
cmd = inchar();
@@ -2756,6 +2816,12 @@ static int do_spu_cmd(void)
case 'r':
restart_spus();
break;
+ case 'f':
+ if (scanhex(&num) && num < XMON_NUM_SPUS && spu_info[num].spu)
+ dump_spu_fields(spu_info[num].spu);
+ else
+ printf("*** Error: invalid spu number\n");
+ break;
default:
return -1;
}
^ permalink raw reply
* Re: plb_temac, ML403, linux 2.4.26, EDK 7.1
From: Andrei Konovalov @ 2006-10-12 12:46 UTC (permalink / raw)
To: robert corley; +Cc: linuxppc-embedded
In-Reply-To: <20061011204632.80180.qmail@web56309.mail.re3.yahoo.com>
Robert,
There is no support for TEMAC in MontaVista Linux 3.1. It has been added in MVL 4.0.1.
In 3.1 there is the gige driver, but gige is for ML300's optical gigabit ethernet, not for TEMAC.
Thanks,
Andrei
robert corley wrote:
> Ming;
>
> Here is what the EDK generates in this file:
>
> C:\EDK\projects\startup_network\ppc405_0\libsrc\linux_mvl31_v1_01_a\linux\arch\ppc\platforms\xilinx_ocp\xparameters_ml300.h
>
> <snip>
> #define XPAR_XTEMAC_NUM_INSTANCES 1
> #define XPAR_PLB_TEMAC_0_BASEADDR 0x60000000
> #define XPAR_PLB_TEMAC_0_HIGHADDR 0x60003FFF
> #define XPAR_PLB_TEMAC_0_DEVICE_ID 0
> #define XPAR_PLB_TEMAC_0_IPIF_RDFIFO_DEPTH 131072
> #define XPAR_PLB_TEMAC_0_IPIF_WRFIFO_DEPTH 131072
> #define XPAR_PLB_TEMAC_0_MAC_FIFO_DEPTH 64
> #define XPAR_PLB_TEMAC_0_DMA_TYPE 3
> #define XPAR_PLB_TEMAC_0_TEMAC_DCR_HOST 0
> #define XPAR_PLB_TEMAC_0_INCLUDE_DRE 1
> <snip>
>
>
> Which is fine. However, the file in the linux distribution: linux_2_4_devel/drivers/net/xilinx_enet/adapter.c is looking for "XEMAC" instead of "XTEMAC" as above.
>
> Also, when I look at the EDK project directory
>
> "C:\EDK\projects\startup_network\ppc405_0\libsrc\linux_mvl31_v1_01_a\linux\drivers\net\"
>
> I see that it is empty. Which means that nothing in the MVL tree will be overwritten (specifically the adapter.c file, which uses the above defines).
>
> So, it appears that the driver is not being properly insterted into the tree as expected. Would you agree?
>
> -R
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: consolidate feature fixup code
From: Olof Johansson @ 2006-10-12 13:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160641793.4792.133.camel@localhost.localdomain>
On Thu, 12 Oct 2006 18:29:53 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> There are currently two versions of the functions for applying the
> feature fixups, one for CPU features and one for firmware features. In
> addition, they are both in assembly.
>
> This patch replaces them with a single C function. The call site is
> slightly moved on ppc64 as well to be called from C instead of from
> assembly, though it's a very small move, and thus shouldn't cause any
> problem (called at the start of setup_system() instead of just before
> calling it).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
>
> Index: linux-cell/arch/powerpc/kernel/head_64.S
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/head_64.S 2006-10-12 14:24:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/head_64.S 2006-10-12 14:24:54.000000000 +1000
> @@ -2000,13 +2000,6 @@ _STATIC(start_here_common)
> li r0,0
> stdu r0,-STACK_FRAME_OVERHEAD(r1)
>
> - /* Apply the CPUs-specific fixups (nop out sections not relevant
> - * to this CPU
> - */
> - li r3,0
> - bl .do_cpu_ftr_fixups
> - bl .do_fw_ftr_fixups
> -
> /* ptr to current */
> LOAD_REG_IMMEDIATE(r4, init_task)
> std r4,PACACURRENT(r13)
> Index: linux-cell/arch/powerpc/kernel/misc_64.S
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/misc_64.S 2006-10-12 14:24:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/misc_64.S 2006-10-12 14:24:54.000000000 +1000
> @@ -277,99 +277,6 @@ _GLOBAL(identify_cpu)
> mr r3,r5
> bctr
>
> -/*
> - * do_cpu_ftr_fixups - goes through the list of CPU feature fixups
> - * and writes nop's over sections of code that don't apply for this cpu.
> - * r3 = data offset (not changed)
> - */
> -_GLOBAL(do_cpu_ftr_fixups)
> - /* Get CPU 0 features */
> - LOAD_REG_IMMEDIATE(r6,cur_cpu_spec)
> - sub r6,r6,r3
> - ld r4,0(r6)
> - sub r4,r4,r3
> - ld r4,CPU_SPEC_FEATURES(r4)
> - /* Get the fixup table */
> - LOAD_REG_IMMEDIATE(r6,__start___ftr_fixup)
> - sub r6,r6,r3
> - LOAD_REG_IMMEDIATE(r7,__stop___ftr_fixup)
> - sub r7,r7,r3
> - /* Do the fixup */
> -1: cmpld r6,r7
> - bgelr
> - addi r6,r6,32
> - ld r8,-32(r6) /* mask */
> - and r8,r8,r4
> - ld r9,-24(r6) /* value */
> - cmpld r8,r9
> - beq 1b
> - ld r8,-16(r6) /* section begin */
> - ld r9,-8(r6) /* section end */
> - subf. r9,r8,r9
> - beq 1b
> - /* write nops over the section of code */
> - /* todo: if large section, add a branch at the start of it */
> - srwi r9,r9,2
> - mtctr r9
> - sub r8,r8,r3
> - lis r0,0x60000000@h /* nop */
> -3: stw r0,0(r8)
> - andi. r10,r4,CPU_FTR_SPLIT_ID_CACHE@l
> - beq 2f
> - dcbst 0,r8 /* suboptimal, but simpler */
> - sync
> - icbi 0,r8
> -2: addi r8,r8,4
> - bdnz 3b
> - sync /* additional sync needed on g4 */
> - isync
> - b 1b
> -
> -/*
> - * do_fw_ftr_fixups - goes through the list of firmware feature fixups
> - * and writes nop's over sections of code that don't apply for this firmware.
> - * r3 = data offset (not changed)
> - */
> -_GLOBAL(do_fw_ftr_fixups)
> - /* Get firmware features */
> - LOAD_REG_IMMEDIATE(r6,powerpc_firmware_features)
> - sub r6,r6,r3
> - ld r4,0(r6)
> - /* Get the fixup table */
> - LOAD_REG_IMMEDIATE(r6,__start___fw_ftr_fixup)
> - sub r6,r6,r3
> - LOAD_REG_IMMEDIATE(r7,__stop___fw_ftr_fixup)
> - sub r7,r7,r3
> - /* Do the fixup */
> -1: cmpld r6,r7
> - bgelr
> - addi r6,r6,32
> - ld r8,-32(r6) /* mask */
> - and r8,r8,r4
> - ld r9,-24(r6) /* value */
> - cmpld r8,r9
> - beq 1b
> - ld r8,-16(r6) /* section begin */
> - ld r9,-8(r6) /* section end */
> - subf. r9,r8,r9
> - beq 1b
> - /* write nops over the section of code */
> - /* todo: if large section, add a branch at the start of it */
> - srwi r9,r9,2
> - mtctr r9
> - sub r8,r8,r3
> - lis r0,0x60000000@h /* nop */
> -3: stw r0,0(r8)
> -BEGIN_FTR_SECTION
> - dcbst 0,r8 /* suboptimal, but simpler */
> - sync
> - icbi 0,r8
> -END_FTR_SECTION_IFSET(CPU_FTR_SPLIT_ID_CACHE)
> - addi r8,r8,4
> - bdnz 3b
> - sync /* additional sync needed on g4 */
> - isync
> - b 1b
>
> #if defined(CONFIG_PPC_PMAC) || defined(CONFIG_PPC_MAPLE)
> /*
> Index: linux-cell/arch/powerpc/kernel/setup-common.c
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/setup-common.c 2006-10-12 14:24:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/setup-common.c 2006-10-12 17:46:02.000000000 +1000
> @@ -520,3 +520,32 @@ void __init setup_panic(void)
> {
> atomic_notifier_chain_register(&panic_notifier_list, &ppc_panic_block);
> }
> +
> +void do_feature_fixups(unsigned long offset, unsigned long value,
> + void *fixup_start, void *fixup_end)
> +{
> + struct fixup_entry {
> + unsigned long mask;
> + unsigned long value;
> + unsigned int *start;
> + unsigned int *end;
> + } *fcur, *fend;
Shouldn't there be a better place to keep this struct definition than
in the function it's used? Some header file?
> +
> + fcur = fixup_start;
> + fend = fixup_end;
> +
> + for (; fcur < fend; fcur++) {
for (fcur = fixup_start; fcur < fend; fcur++) {
> + unsigned int *pcur, *pend;
> +
> + if ((value & fcur->mask) == fcur->value)
> + continue;
> +
> + pcur = fcur->start - offset;
> + pend = fcur->end - offset;
> + for (; pcur < pend; pcur++) {
> + *pcur = 0x60000000u;
> + asm ("dcbst 0, %0; sync; icbi 0,%0; sync; isync"
> + : : "r" (pcur));
> + }
Ok, now it's in C, no reason to do a dcbst/icbi for every word. We did
it in asm for simplicity's sake. Split it in two loops, one to nop,
second to step per line and do the flushes. :-)
> + }
> +}
> Index: linux-cell/arch/powerpc/kernel/setup.h
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/setup.h 2006-10-12 14:24:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/setup.h 2006-10-12 17:46:02.000000000 +1000
> @@ -1,9 +1,12 @@
> #ifndef _POWERPC_KERNEL_SETUP_H
> #define _POWERPC_KERNEL_SETUP_H
>
> -void check_for_initrd(void);
> -void do_init_bootmem(void);
> -void setup_panic(void);
> +extern void check_for_initrd(void);
> +extern void do_init_bootmem(void);
> +extern void setup_panic(void);
> +extern void do_feature_fixups(unsigned long offset, unsigned long value,
> + void *fixup_start, void *fixup_end);
> +
> extern int do_early_xmon;
>
> #endif /* _POWERPC_KERNEL_SETUP_H */
> Index: linux-cell/arch/powerpc/kernel/setup_32.c
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/setup_32.c 2006-10-12 14:24:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/setup_32.c 2006-10-12 17:46:24.000000000 +1000
> @@ -90,6 +90,7 @@ int ucache_bsize;
> */
> unsigned long __init early_init(unsigned long dt_ptr)
> {
> + extern unsigned int __start___ftr_fixup, __stop___ftr_fixup;
> unsigned long offset = reloc_offset();
>
> /* First zero the BSS -- use memset_io, some platforms don't have
> @@ -101,7 +102,9 @@ unsigned long __init early_init(unsigned
> * that depend on which cpu we have.
> */
> identify_cpu(offset, 0);
> - do_cpu_ftr_fixups(offset);
> +
> + do_feature_fixups(offset, cur_cpu_spec->cpu_features,
> + &__start___ftr_fixup, &__stop___ftr_fixup);
>
> return KERNELBASE + offset;
> }
> Index: linux-cell/arch/powerpc/kernel/setup_64.c
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/setup_64.c 2006-10-12 14:24:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/setup_64.c 2006-10-12 17:46:18.000000000 +1000
> @@ -346,8 +346,19 @@ static void __init initialize_cache_info
> */
> void __init setup_system(void)
> {
> + extern unsigned int __start___ftr_fixup, __stop___ftr_fixup;
> + extern unsigned int __start___fw_ftr_fixup, __stop___fw_ftr_fixup;
> +
> DBG(" -> setup_system()\n");
>
> + /* Apply the CPUs-specific and firmware specific fixups to kernel
> + * text (nop out sections not relevant to this CPU or this firmware)
> + */
> + do_feature_fixups(0, cur_cpu_spec->cpu_features,
> + &__start___ftr_fixup, &__stop___ftr_fixup);
> + do_feature_fixups(0, powerpc_firmware_features,
> + &__start___fw_ftr_fixup, &__stop___fw_ftr_fixup);
> +
> /*
> * Unflatten the device-tree passed by prom_init or kexec
> */
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Cell timebase workaround
From: Olof Johansson @ 2006-10-12 14:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160641804.4792.136.camel@localhost.localdomain>
On Thu, 12 Oct 2006 18:30:04 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> The Cell CPU timebase has an errata. When reading the entire 64 bits of
> the timebase with one mftb instruction, there is a handful of cycles
> window during which one might read a value with the low order 32 bits
> already reset to 0x00000000 but the high order bits not yet incremeted
> by one. Simply reading the timebase a second time if the low order bits
> are 0 is enough (the second read will always miss that window).
>
> Note that there is still a potential issue if the process gets
> interrupted between the 2 reads for long enough that the second reads
> pricely hits that same window on the next 32 bits wrap. However, this is
> so extremely unlikely to happen that we choose not to do anything
> against it (the 32 bits wrap happens every few seconds or so, in fact
> every few minutes on IBM cell blades).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> This is the "old" patch adapted to apply on top of the previous changes.
> I'll post tomorrow a new version of the patch using a different
> technique for the workaround
>
> Index: linux-cell/arch/powerpc/kernel/vdso64/gettimeofday.S
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/vdso64/gettimeofday.S 2006-10-12 18:08:40.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/vdso64/gettimeofday.S 2006-10-12 18:18:15.000000000 +1000
> @@ -11,6 +11,7 @@
> * as published by the Free Software Foundation; either version
> * 2 of the License, or (at your option) any later version.
> */
> +
> #include <asm/processor.h>
> #include <asm/ppc_asm.h>
> #include <asm/vdso.h>
> @@ -229,8 +230,13 @@ V_FUNCTION_BEGIN(__do_get_xsec)
> xor r0,r8,r8 /* create dependency */
> add r3,r3,r0
>
> - /* Get TB & offset it */
> - mftb r7
> + /* Get TB & offset it. We use the MFTB macro which will generate
> + * workaround code for Cell. The macro will generate the ELF bits
> + * for the CPU feature fixup though those aren't actually applied
> + * on the vDSO, which means that the workaround will always be
> + * executed if CONFIG_PPC_CELL is set.
> + */
> + MFTB(r7)
> ld r9,CFG_TB_ORIG_STAMP(r3)
> subf r7,r9,r7
>
> Index: linux-cell/include/asm-powerpc/cputable.h
> ===================================================================
> --- linux-cell.orig/include/asm-powerpc/cputable.h 2006-10-12 18:17:44.000000000 +1000
> +++ linux-cell/include/asm-powerpc/cputable.h 2006-10-12 18:18:15.000000000 +1000
> @@ -144,6 +144,7 @@ extern void do_cpu_ftr_fixups(unsigned l
> #define CPU_FTR_CI_LARGE_PAGE LONG_ASM_CONST(0x0000100000000000)
> #define CPU_FTR_PAUSE_ZERO LONG_ASM_CONST(0x0000200000000000)
> #define CPU_FTR_PURR LONG_ASM_CONST(0x0000400000000000)
> +#define CPU_FTR_CELL_TB_BUG LONG_ASM_CONST(0x0000800000000000)
>
> #ifndef __ASSEMBLY__
>
> @@ -332,7 +333,7 @@ extern void do_cpu_ftr_fixups(unsigned l
> #define CPU_FTRS_CELL (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
> CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
> - CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE)
> + CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE | CPU_FTR_CELL_TB_BUG)
> #define CPU_FTRS_PA6T (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
> CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
> CPU_FTR_ALTIVEC_COMP | CPU_FTR_CI_LARGE_PAGE | \
> Index: linux-cell/include/asm-powerpc/ppc_asm.h
> ===================================================================
> --- linux-cell.orig/include/asm-powerpc/ppc_asm.h 2006-10-12 18:08:40.000000000 +1000
> +++ linux-cell/include/asm-powerpc/ppc_asm.h 2006-10-12 18:18:15.000000000 +1000
> @@ -29,10 +29,10 @@
> BEGIN_FTR_SECTION; \
> mfspr ra,SPRN_PURR; /* get processor util. reg */ \
> END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
> -BEGIN_FTR_SECTION; \
> - mftb ra; /* or get TB if no PURR */ \
> -END_FTR_SECTION_IFCLR(CPU_FTR_PURR); \
> - ld rb,PACA_STARTPURR(r13); \
> +BEGIN_FTR_SECTION_NESTED(96); \
> + MFTB(ra); /* or get TB if no PURR */ \
> +END_FTR_SECTION_NESTED(CPU_FTR_PURR, 0, 96); \
> + ld rb,PACA_STARTPURR(r13); \
> std ra,PACA_STARTPURR(r13); \
> subf rb,rb,ra; /* subtract start value */ \
> ld ra,PACA_USER_TIME(r13); \
> @@ -44,9 +44,9 @@ END_FTR_SECTION_IFCLR(CPU_FTR_PURR);
> BEGIN_FTR_SECTION; \
> mfspr ra,SPRN_PURR; /* get processor util. reg */ \
> END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
> -BEGIN_FTR_SECTION; \
> - mftb ra; /* or get TB if no PURR */ \
> -END_FTR_SECTION_IFCLR(CPU_FTR_PURR); \
> +BEGIN_FTR_SECTION_NESTED(96); \
> + MFTB(ra); /* or get TB if no PURR */ \
> +END_FTR_SECTION_NESTED(CPU_FTR_PURR, 0, 96); \
> ld rb,PACA_STARTPURR(r13); \
> std ra,PACA_STARTPURR(r13); \
> subf rb,rb,ra; /* subtract start value */ \
> @@ -274,6 +274,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_601)
> #define ISYNC_601
> #endif
>
> +#ifdef CONFIG_PPC_CELL
> +#define MFTB(dest) \
> + mftb dest; \
> +BEGIN_FTR_SECTION; \
> + cmpwi dest,0; \
> + bne+ 90f; \
> + mftb dest; \
> +90: \
> +END_FTR_SECTION_IFSET(CPU_FTR_CELL_TB_BUG)
> +#else
> +#define MFTB(dest) mftb dest
> +#endif
The above is a bit obfuscated. Please make the MFTB() macro use the
nested version of the feature definitions, and let the surrounding code
use the base one. Otherwise it will be really easy to mix them up by
mistake, there's no exposure at the time of MFTB() usage that it uses
feature labels.
-Olof
^ permalink raw reply
* Xilinx I2C driver for linux 2.6?
From: Jean-Baptiste Maneyrol @ 2006-10-12 14:35 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody!
Does anyone know if there is somewhere an i2c driver for the Xilinx IIC IP
working on linux 2.6?
I'm using the ML405 board with EDK 8.2i, and their driver is for linux 2.4.
Thanks!
Jean-Baptiste Maneyrol
Teamlog - France
________________________________________________
Message sent using UebiMiau 2.7.9
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: consolidate feature fixup code
From: Benjamin Herrenschmidt @ 2006-10-12 14:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list
In-Reply-To: <20061012085617.3a5d6a31@localhost.localdomain>
> > +void do_feature_fixups(unsigned long offset, unsigned long value,
> > + void *fixup_start, void *fixup_end)
> > +{
> > + struct fixup_entry {
> > + unsigned long mask;
> > + unsigned long value;
> > + unsigned int *start;
> > + unsigned int *end;
> > + } *fcur, *fend;
>
> Shouldn't there be a better place to keep this struct definition than
> in the function it's used? Some header file?
It's not used anywhere else.... which header would you put it in ?
> > +
> > + fcur = fixup_start;
> > + fend = fixup_end;
> > +
> > + for (; fcur < fend; fcur++) {
>
> for (fcur = fixup_start; fcur < fend; fcur++) {
>
> > + unsigned int *pcur, *pend;
> > +
> > + if ((value & fcur->mask) == fcur->value)
> > + continue;
> > +
> > + pcur = fcur->start - offset;
> > + pend = fcur->end - offset;
> > + for (; pcur < pend; pcur++) {
> > + *pcur = 0x60000000u;
> > + asm ("dcbst 0, %0; sync; icbi 0,%0; sync; isync"
> > + : : "r" (pcur));
> > + }
>
> Ok, now it's in C, no reason to do a dcbst/icbi for every word. We did
> it in asm for simplicity's sake. Split it in two loops, one to nop,
> second to step per line and do the flushes. :-)
Do we care ? :) But yah, I suppose I can do that.
Thanks,
Ben.
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Cell timebase workaround
From: Benjamin Herrenschmidt @ 2006-10-12 14:48 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list
In-Reply-To: <20061012091455.6409046e@localhost.localdomain>
> The above is a bit obfuscated. Please make the MFTB() macro use the
> nested version of the feature definitions, and let the surrounding code
> use the base one. Otherwise it will be really easy to mix them up by
> mistake, there's no exposure at the time of MFTB() usage that it uses
> feature labels.
Yup, I was thinking about doing that at one point and it slipped out of
my mind. Thanks for reminding me :)
Cheers,
Ben.
^ permalink raw reply
* Re: Handling machine check exception
From: Benjamin Herrenschmidt @ 2006-10-12 14:51 UTC (permalink / raw)
To: Matt Sealey; +Cc: ganesh subramonian, linuxppc-dev
In-Reply-To: <452E1A1D.1050601@genesi-usa.com>
On Thu, 2006-10-12 at 12:34 +0200, Matt Sealey wrote:
> The G2 core definitely has a DAR register (SPR 19).
>
> Look on the Freescale site for G2CORERM.pdf - this is
> your reference manual, not the one specifically for the
> 8247.
Is DAR set for a machine check ?
Ben.
^ permalink raw reply
* Modules_install (depmod) prob
From: srideep.devireddy @ 2006-10-12 14:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2966 bytes --]
Hi ,
I am trying to compile mvista linux , I am able to run make dep ,
make zImage successfully after I do make modules and make
modules_install .
I am struck with below errors , I found that depmod which is x86 cant
execute it on the modules created for Arm . can any one give me any
suggestion to bypass this and make depmod as crosscompile or over come
this problem . I got few out by googling that we have to change few
CFLAGS or depmod.pl , if any one has used it please let me know .Thanks
in advance ..
Log
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{}
pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map
2.4.19-rmk7-ds3-mw1; fi
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr.o not for this
architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_atmdAcc.o not
for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_atmm.o not for
this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_atmsch.o not for
this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_atmDemo
.o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_cryptoA
cc.o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_demoUti
ls.o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_dmaAcc.
o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_ethAal5
App.o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_ethAcc.
o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_fpathAc
c.o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_hssAcc.
o not for this architecture
depmod: ELF file
/lib/modules/2.4.19-rmk7-ds3-mw1/kernel/drivers/csr/csr_codelets_oam.o
not for this architecture
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
[-- Attachment #2: Type: text/html, Size: 7399 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: consolidate feature fixup code
From: Olof Johansson @ 2006-10-12 14:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160664449.4792.147.camel@localhost.localdomain>
On Fri, 13 Oct 2006 00:47:29 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > > +void do_feature_fixups(unsigned long offset, unsigned long value,
> > > + void *fixup_start, void *fixup_end)
> > > +{
> > > + struct fixup_entry {
> > > + unsigned long mask;
> > > + unsigned long value;
> > > + unsigned int *start;
> > > + unsigned int *end;
> > > + } *fcur, *fend;
> >
> > Shouldn't there be a better place to keep this struct definition than
> > in the function it's used? Some header file?
>
> It's not used anywhere else.... which header would you put it in ?
Near where the asm-corresponding ones are located (cputable.h).
-Olof
> > Ok, now it's in C, no reason to do a dcbst/icbi for every word. We did
> > it in asm for simplicity's sake. Split it in two loops, one to nop,
> > second to step per line and do the flushes. :-)
>
> Do we care ? :) But yah, I suppose I can do that.
Close call. :-) It's just easier to do now, might as well do it. But
yeah, no big deal.
It will also be easier to graft in a branch forward instead of a large
amount of nops for large feature sections. I guess it will take some
benchmarking to see what the breakeven point is.
-Olof
^ permalink raw reply
* Re: Xilinx I2C driver for linux 2.6?
From: Peter Korsgaard @ 2006-10-12 15:24 UTC (permalink / raw)
To: linuxppc-embedded
>>>>> "JBM" == Jean-Baptiste Maneyrol <MANE@teamlog.com> writes:
Hi,
JBM> Does anyone know if there is somewhere an i2c driver for the
JBM> Xilinx IIC IP working on linux 2.6?
Not afaik. We're using the OpenCores I2C controller instead which I in
the mean time have written a driver for (in mainline). The IP core is
afaik even smaller than the Xilinx controller.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: consolidate feature fixup code
From: Benjamin Herrenschmidt @ 2006-10-12 15:24 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list
In-Reply-To: <20061012095649.23bb6b35@localhost.localdomain>
> It will also be easier to graft in a branch forward instead of a large
> amount of nops for large feature sections. I guess it will take some
> benchmarking to see what the breakeven point is.
Yeah, I've been thinking about that one for some time (in fact since I
did the first implementation of feature fixup). Thing is, back when it
was all asm, it was hard, and we never really had big feature sections.
Now that we have all that stuff with with PURR etc... in the exception
entry/return path, it might be worth having another look. I suspect that
the breakeven point will be very CPU dependant tho.
Ben.
^ permalink raw reply
* Re: Xilinx I2C driver for linux 2.6?
From: David Hawkins @ 2006-10-12 15:37 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <877iz5wo8q.fsf@sleipner.barco.com>
> Not afaik. We're using the OpenCores I2C controller instead which I in
> the mean time have written a driver for (in mainline). The IP core is
> afaik even smaller than the Xilinx controller.
>
Peter, whats the name of the driver in mainline?
(Denx git or kernel.org?)
I want to use the opencore IP in a memory mapped
FPGA (Altera though), so would like to take a look
at your driver.
Cheers,
Dave
^ permalink raw reply
* Recently removed io accessors
From: Peter Korsgaard @ 2006-10-12 15:44 UTC (permalink / raw)
To: sfr; +Cc: linuxppc-dev
Hi,
Commit 661f1cdb8b3e3c2c44e97df122c1d5643c054ce8 ([POWERPC] remove
unused asm routines) removed the _insl / _outsl routines for 32bit
copies with byteswap.
I've been working on adding ppc support to drivers/net/smc911x.c, and
I was unfortunately using those routines (The ethernet controller can
be configured for big endian mode, but the contents of the internal
packet buffers is still little endian, so you need to byteswap in the
tx/rx routines).
Any chance of getting them back or should I implement a (slower) loop
myself before submitting the patch?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: Xilinx I2C driver for linux 2.6?
From: Peter Korsgaard @ 2006-10-12 15:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <452E612D.1070301@ovro.caltech.edu>
>>>>> "DH" == David Hawkins <dwh@ovro.caltech.edu> writes:
Hi,
DH> Peter, whats the name of the driver in mainline? (Denx git or
DH> kernel.org?)
Kernel.org - drivers/i2c/busses/i2c-ocores.c
Also take a look at Documentation/i2c/busses/i2c-ocores.
DH> I want to use the opencore IP in a memory mapped FPGA (Altera
DH> though), so would like to take a look at your driver.
You're welcome. It should be pretty easy to get going (just provide a
platform device with addr/irq).
--
Bye, Peter Korsgaard
^ permalink raw reply
* plb_temac, EDK 8.1 et al
From: robert corley @ 2006-10-12 16:15 UTC (permalink / raw)
To: Rick Moleres; +Cc: linuxppc-embedded
Rick;=0A=0AThanks so much for the reply.=0A=0AAs I understand your email=0A=
=0AEDK 7.1 vs. EDK 8.1=0A gets the *best* plb_temac I need to upgrade th=
e EDK,=0A I can stick with 7.1 if I am satisfied with the lower performa=
nce,=0A MVL drivers in source tree of EDK (sw/Thirdparty...)=0A=0Alinux =
2.4 vs. linux 2.6=0A plb_temac drivers already done=0A plb_temac avai=
lable in 2.4 via use of xilinx_gige directory=0A=0A-cy=0A
^ permalink raw reply
* RE: plb_temac, ML403, linux 2.4.26, EDK 7.1
From: Rick Moleres @ 2006-10-12 15:55 UTC (permalink / raw)
To: Robert Corley; +Cc: linuxppc-embedded
Robert,
(I copied the list)
Linux 2.4 support for plb_temac was not added until EDK 8.1.1. This
driver is not available in the MV Linux 2.4 tree. So if you want
something (the driver) to show up in libsrc/linux_mvl31_v1_01_b/linux
then you would need to upgrade.
Note also that checksum offload was added to the plb_temac core in EDK
8.1.2 (v3.00a of the core), so using that EDK or later will provide much
better GigE throughput (I think we measured somewhere around 650Mbps TCP
traffic using netperf on Linux 2.4 with checksum offload).
In Linux 2.4 we place the plb_temac driver in drivers/net/xilinx_gige
during the BSP generation process of EDK 8.1.1 or later in order to take
advantage of the jumbo frame config option. I looked at
source.mvista.com and this directory does appear in the Linux 2.4
repository (rsync://source.mvista.com/linuxppc-2.4).
Hope that helps,
Rick
-----Original Message-----
From: Robert Corley [mailto:rcorley@aegis-inc.net]=20
Sent: Wednesday, October 11, 2006 10:16 AM
To: Rick Moleres
Subject: Fw: plb_temac, ML403, linux 2.4.26, EDK 7.1
Rick,
Apologies for some potentially confusing parts of my last email to you.
Here is what I just posted if you care to reply.
----- Forwarded Message ----
From: robert corley <rdcorle@yahoo.com>
To: linuxppc-embedded@ozlabs.org
Sent: Wednesday, October 11, 2006 12:14:51 PM
Subject: plb_temac, ML403, linux 2.4.26, EDK 7.1
Some background:
ML403 devel board
EDK 7.1
compilation of reference design xapp902, modified to use linux and
without loopback
use of linux_2_4_devel obtained from montavista via rsync
I am trying to use the plb_temac rather than the ll_temac. In the long
run, I'd prefer to stick with linux 2.4. In addition, I will need to
get both embedded EMAC's up and running, but first I just wanna get the
xapp902 working. Also, I will need gigE support.
So, right now I am trying to get the plb_temac to compile and get errors
about the defines XPAR_XTEMAC_* within the linux directories
../drivers/net/xilinx_enet. I see that the edk gets the defines within
the xparameters.h file of the xapp902 project. I also see that my
C:\EDK\sw\ThirdParty\bsp\linux_mvl31_v1_01_a\drivers don't have anything
for a plb_temac.
Q: Is my error related to an incorrect setup of the linux or with the
EDK?
Q: t is stated that the plb_temac drivers are in EDK 8.1. Can I
stick
with 7.1 or must I ugprade?
Q: Where in the linux tree should I look for the xtemac
stuff? Is this what the EDK pushes on to the tree or is it released
within the MVL distro?
Q Based on posts by David and Ming, it
appears that I must use xilinx_gige to get up to gigE speeds. Will the
plb_temac support this data rate and, if so, is this a transparent
support or do I need to go the route suggested to Ming and
overwrite files in xilinx_enet?
R. Corley
^ permalink raw reply
* Re: [PATCH 1/2] Add support for stopping spus from xmon
From: Linas Vepstas @ 2006-10-12 16:18 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <20061012120310.6B5A967BD5@ozlabs.org>
On Thu, Oct 12, 2006 at 10:03:08PM +1000, Michael Ellerman wrote:
>
> arch/powerpc/platforms/cell/spu_base.c | 4
> arch/powerpc/xmon/xmon.c | 142 ++++++++++++++++++++++++++++++++-
> include/asm-powerpc/xmon.h | 2
> 3 files changed, 146 insertions(+), 2 deletions(-)
The next patch adds another 60 lines to xmon.c, which
is already a bit too big. Perhaps you could instead
put this code in "xmon/cell.c" or something like that?
--linas
^ permalink raw reply
* Re: Problems with DMA from user space on MPC834x (Cache coherency?)
From: Manish Joshi @ 2006-10-12 17:32 UTC (permalink / raw)
To: Lauri Ehrenpreis, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3216 bytes --]
Yeah it looks like a cache coherency problem from the first look.
You may try enabling snooping on the DMA channel if MPC824X supports it. Check in Mode register setting.
Else you may want to use flush_dcache_range(start, last) functions and see if it helps.
----- Original Message ----
From: Lauri Ehrenpreis <lauri.ehrenpreis@liewenthal.ee>
To: linuxppc-embedded@ozlabs.org
Sent: Wednesday, October 11, 2006 7:20:03 AM
Subject: Problems with DMA from user space on MPC834x (Cache coherency?)
Hi!
I have a problem with DMA from user space on a platform powered by MPC834x
processor (which has powerpc e300 core inside). Our linux kernel version is
2.6.17.
My user space program does something like this:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma();
while /disk is mounted to a partition residing on USB memory stick or SD
card.
page_aligned_buf starts from page boundary and contains enough full pages
for
the data (so I can allways map full page with dma_map_page in kernel).
The buffer address and data length will then be passed to a driver, which
calls
get_user_pages, then maps each page with dma_map_page and tells a PCI
device
to start reading from that page:
...
down_read(¤t->mm->mmap_sem);
result = get_user_pages(current, current->mm, page_aligned_buf, nr_pages,
0, 0, pages, NULL);
up_read(¤t->mm->mmap_sem);
for (i = 0; i < nr_pages; i++) {
find_data_checksum(pages[i]);
dma_addr = dma_map_page(&fpga.pci_dev->dev, pages[i], 0, PAGE_SIZE,
DMA_TO_DEVICE);
start_dma();
wait_until_dma_ready();
dma_unmap_page(&fpga.pci_dev->dev, dma_addr, dma_len, DMA_TO_DEVICE);
if(!checksum_ok_in_fpga())
print_page_data();
}
for (i = 0; i < nr_pages; i++)
page_cache_release(pages[i]);
The problem is that sometimes the PCI device receives wrong bytes at random
locations. I find the data checksum inside the driver and inside the FPGA.
Inside the driver I use kmap(page) and kunmap(page) to access data on the
user page. Sometimes the checksums do not match and I can see with the FPGA
debugging tool, that the FPGA receives different data than the driver is
printing out.
I have noticed 3 things regarding this error:
1) When I copy the data I read from the block device to another buffer in
userspace and pass this new buffer to the driver, then this error will
never occur:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
memcpy(new_page_aligned_buf, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma(new_page_aligned_buf, len);
2) this error does not occur when I use copy_from_user instead of
get_user_pages
and dma_map_page inside driver.
3) this error does not occur on our previuos device, which has x86
platform.
I am currently out of ideas what to do next.. It seems to me like a cache
coherency problem. Can anyone suggest what might be wrong?
--
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 4713 bytes --]
^ permalink raw reply
* lite5200B boot up error with PCI card
From: prashanth epuru @ 2006-10-12 17:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 2335 bytes --]
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 2/2] Add support for dumping spu info from xmon
From: Geoff Levand @ 2006-10-12 17:42 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <20061012120312.10FDD67BE5@ozlabs.org>
Michael Ellerman wrote:
> This patch adds a command to xmon for dumping information about
> spu structs. The command is 'sf' for "spu fields" perhaps, and
> takes the spu number as an argument. This is the same value as the
> spu->number field, or the "phys-id" value of a context when it is
> bound to a physical spu.
> +static void dump_spu_fields(struct spu *spu)
> +{
...
> + DUMP_FIELD(spu, "0x%x", problem->spu_npc_RW);
> + DUMP_FIELD(spu, "0x%p", priv1);
> +
> + if (spu->priv1)
> + DUMP_FIELD(spu, "0x%lx", priv1->mfc_sr1_RW);
> +
> + DUMP_FIELD(spu, "0x%p", priv2);
Just to let you know, I've been doing some work to abstract the platform
specific parts out of the spu support to better support running on a
hypervisor. It shouldn't make much difference, but maybe I'll try to set
something up like this for you:
DUMP_FIELD(spu, "0x%x", problem->spu_npc_RW);
DUMP_FIELD(spu, "0x%p", priv2);
spu_dump_platform_fields(spu);
-Geoff
^ permalink raw reply
* Re: lite5200B boot up error with PCI card
From: Wolfgang Denk @ 2006-10-12 18:33 UTC (permalink / raw)
To: prashanth epuru; +Cc: linuxppc-embedded
In-Reply-To: <20061012135311.HM.0000000000000BP@epuru.bos-mail-wwl4.lycos.com>
In message <20061012135311.HM.0000000000000BP@epuru.bos-mail-wwl4.lycos.com> you wrote:
>
> >I am trying to boot up lite5200B version 1.0 freescale board with u boot and it boots up properly without any PCI card.
> The lite5200B crashes while bootup if a PCI card (PCI to mini PCI converter card of Catalyst Enterprises) is inserted.
...
> U-Boot 1.1.3 (Aug 10 2005 - 11:07:57)
No big surprise. Support for the Lite500B was added much later. You
should update U-Boot to the latest version (= top of tree in git
repository).
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
"Life sucks, but it's better than the alternative."
- Peter da Silva
^ permalink raw reply
* Re: Handling machine check exception
From: Segher Boessenkool @ 2006-10-12 20:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ganesh subramonian, linuxppc-dev
In-Reply-To: <1160664666.4792.151.camel@localhost.localdomain>
>> The G2 core definitely has a DAR register (SPR 19).
>>
>> Look on the Freescale site for G2CORERM.pdf - this is
>> your reference manual, not the one specifically for the
>> 8247.
>
> Is DAR set for a machine check ?
Not on these old cores.
Segher
^ 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