LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 3/3 2.6.24-git] PPC/LIBATA: Select HAVE_PATA_PLATFORM for ARCH_PPC
From: Ben Dooks @ 2008-02-02 16:21 UTC (permalink / raw)
  To: linux-ide, jeff, htejun; +Cc: linuxppc-dev, Ben Dooks
In-Reply-To: <20080202162133.678366209@fluff.org.uk>

Use the new HAVE_PATA_PLATFORM to select PATA_PLATFORM
driver.

CC: linuxppc-dev@ozlabs.org
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

Index: linux-2.6.24-git12-pata2/arch/ppc/Kconfig
===================================================================
--- linux-2.6.24-git12-pata2.orig/arch/ppc/Kconfig
+++ linux-2.6.24-git12-pata2/arch/ppc/Kconfig
@@ -41,6 +41,7 @@ config GENERIC_CALIBRATE_DELAY
 
 config PPC
 	bool
+	select HAVE_PATA_PLATFORM
 	default y
 
 config PPC32
Index: linux-2.6.24-git12-pata2/drivers/ata/Kconfig
===================================================================
--- linux-2.6.24-git12-pata2.orig/drivers/ata/Kconfig
+++ linux-2.6.24-git12-pata2/drivers/ata/Kconfig
@@ -624,7 +624,7 @@ config HAVE_PATA_PLATFORM
 
 config PATA_PLATFORM
 	tristate "Generic platform device PATA support"
-	depends on EMBEDDED || PPC || HAVE_PATA_PLATFORM
+	depends on EMBEDDED || HAVE_PATA_PLATFORM
 	help
 	  This option enables support for generic directly connected ATA
 	  devices commonly found on embedded systems.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

^ permalink raw reply

* Re: Kernel oops while duming user core.
From: Clemens Koller @ 2008-02-02 12:05 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <20080201173834.GD671@ld0162-tx32.am.freescale.net>

Scott Wood schrieb:
> On Thu, Jan 31, 2008 at 10:15:27AM -0600, Nathan Lynch wrote:
>> Rune Torgersen wrote:
>>> I get the following kernel core while a user program I have is dumping
>>> core.
>>> Any DIeas at what to look for? (this is runnign 2.6.24, arch/powerpc on
>>> a 8280)
>>> When runnign the program on 2.6.18 arch/ppc, the program gets a sig 11
>>> and dumps core.
>>> On 2.6.24, I ghet the kernel oops, and then the program hangs sround
>>> forever and is unkillable.
>> Hmm, this is the second report of 2.6.24 crashing in
>> __flush_dcache_icache during a core dump; see:
>> http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048662.html
>>
>> Is this easily recreatable?
> 
> Yes, this program does it reliably:
> 
> #include <pthread.h>
> #include <stdio.h>
> #include <unistd.h>
> #include <signal.h>
> 
> void *threadfn(void *arg)
> {
> 	fprintf(stderr, "threadfn\n");
> 	fflush(stderr);
> 	sleep(1);
> 	*(char *)0=0;
> 	return NULL;
> }
> 
> int main(void)
> {
> 	pthread_t thread[4];
> 	int i;
> 
> 	for (i = 0; i < 4; i++)
> 		pthread_create(&thread[0], NULL, threadfn, NULL);
> 
> 	for (;;);
> }

Ack!

This is a MPC8540ADS arch/powerpc compatible environment here:

Feb  2 12:59:17 fox_1 kernel: Unable to handle kernel paging request for data at address 0x4802f000
Feb  2 12:59:17 fox_1 kernel: Faulting instruction address: 0xc000d5b8
Feb  2 12:59:17 fox_1 kernel: Oops: Kernel access of bad area, sig: 11 [#1]
Feb  2 12:59:17 fox_1 kernel: MPC85xx ADS
Feb  2 12:59:17 fox_1 kernel: Modules linked in:
Feb  2 12:59:17 fox_1 kernel: NIP: c000d5b8 LR: c0010fb8 CTR: 00000080
Feb  2 12:59:17 fox_1 kernel: REGS: c24abb20 TRAP: 0300   Not tainted  (2.6.24)
Feb  2 12:59:17 fox_1 kernel: MSR: 00029000 <EE,ME>  CR: 22882222  XER: 00000000
Feb  2 12:59:17 fox_1 kernel: DEAR: 4802f000, ESR: 00000000
Feb  2 12:59:17 fox_1 kernel: TASK = cf894d20[942] 'oops' THREAD: c24aa000
Feb  2 12:59:17 fox_1 kernel: GPR00: c22c7680 c24abbd0 cf894d20 4802f000 00000080 000f8b60 4802f000 ffffffff
Feb  2 12:59:17 fox_1 kernel: GPR08: 00000000 c22c7680 000008d1 00000000 22882222 10018a64 00000006 c035a300
Feb  2 12:59:17 fox_1 kernel: GPR16: 00024000 c0380000 c24aa000 c24abc9c c24abc98 c2570480 c22c7680 c0380000
Feb  2 12:59:17 fox_1 kernel: GPR24: c0390420 cf09d000 c0497b60 c5b63948 4802f000 c24aa000 000000bc c0497b60
Feb  2 12:59:17 fox_1 kernel: NIP [c000d5b8] __flush_dcache_icache+0x14/0x40
Feb  2 12:59:17 fox_1 kernel: LR [c0010fb8] update_mmu_cache+0x94/0x98
Feb  2 12:59:17 fox_1 kernel: Call Trace:
Feb  2 12:59:17 fox_1 kernel: [c24abbd0] [c24aa000] 0xc24aa000 (unreliable)
Feb  2 12:59:17 fox_1 kernel: [c24abbe0] [c005d978] handle_mm_fault+0x374/0x6a4
Feb  2 12:59:17 fox_1 kernel: [c24abc30] [c005ddd0] get_user_pages+0x128/0x384
Feb  2 12:59:17 fox_1 kernel: [c24abc90] [c00a80d8] elf_core_dump+0xab8/0xb74
Feb  2 12:59:17 fox_1 kernel: [c24abd30] [c007718c] do_coredump+0x730/0x758
Feb  2 12:59:17 fox_1 kernel: [c24abe30] [c002eeb0] get_signal_to_deliver+0x244/0x3c4
Feb  2 12:59:17 fox_1 kernel: [c24abe80] [c000782c] do_signal+0x48/0x264
Feb  2 12:59:17 fox_1 kernel: [c24abf40] [c000e4ac] do_user_signal+0x74/0xc4
Feb  2 12:59:17 fox_1 kernel: Instruction dump:
Feb  2 12:59:17 fox_1 kernel: 4d820020 7c8903a6 7c001bac 38630020 4200fff8 7c0004ac 4e800020 60000000
Feb  2 12:59:17 fox_1 kernel: 54630026 38800080 7c8903a6 7c661b78 <7c00186c> 38630020 4200fff8 7c0004ac
Feb  2 12:59:17 fox_1 kernel: ---[ end trace a1d91e665173315a ]---
Feb  2 12:59:17 fox_1 kernel: note: oops[942] exited with preempt_count 1

It does not oops when the core dump is disabled.

Regards,

Clemens

^ permalink raw reply

* Re: PATCH[1/1] 8xx: Add clock-frequency to Adder875 and mpc885ads board ports
From: Bryan O'Donoghue @ 2008-02-02 11:36 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47A38888.1010901@freescale.com>

On Fri, 2008-02-01 at 15:00 -0600, Scott Wood wrote:
> Bryan O'Donoghue wrote:
> > Redo the addition of the clock-frequency parameter to the Adder875 .dts
> > so that the values are decimal rather then hex.
> > 
> > 
> > Signed-off-by: Bryan O'Donoghue <bodonoghue@codehermit.ie>
> > ---
> > 
> > diff --git a/arch/powerpc/boot/dts/adder875-redboot.dts
> > b/arch/powerpc/boot/dts/adder875-redboot.dts
> > index 7c25d96..c508f3c 100644
> > --- a/arch/powerpc/boot/dts/adder875-redboot.dts
> > +++ b/arch/powerpc/boot/dts/adder875-redboot.dts
> > @@ -149,6 +149,7 @@
> >                                 compatible = "fsl,mpc875-brg",
> >                                              "fsl,cpm1-brg",
> >                                              "fsl,cpm-brg";
> > +                               clock-frequency = <50000000>;
> >                                 reg = <0x9f0 0x10>;
> >                         };

Actually I was wondering myself why the file was using whitespace
instead of tabs - no doubt something to do with copying between
evolution + gedit.

Will fix this up with vim

^ permalink raw reply

* Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
From: Yuri Tikhonov @ 2008-02-02 11:30 UTC (permalink / raw)
  To: Jochen Friedrich; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <47A45269.7080403@scram.de>


 Hi Jochen,

 The board for which this fix was developed is one of these (ivms8). Here are 
some other: rpxlite, TQM860L, rpxcllf, bseip, FADS, and etc...

  Just do grep -r "CONFIG_8xx=y" arch/ppc/configs/ and grep -r "CONFIG_8xx=y" 
arch/powerpc/configs/ :)

 Regards, Yuri

On Saturday 02 February 2008 14:22, you wrote:
...
> >  Here is the patch which makes Linux-2.6 swap routines operate correctly 
on
> > the ppc-8xx-based machines.
> 
> is there any 8xx board left which isn't ported to ARCH=powerpc?
> 
> Thanks,
> Jochen 
> 

-- 
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com

^ permalink raw reply

* Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
From: Jochen Friedrich @ 2008-02-02 11:22 UTC (permalink / raw)
  To: Yuri Tikhonov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200802021047.32055.yur@emcraft.com>

Hi Yuri,

>  Here is the patch which makes Linux-2.6 swap routines operate correctly on
> the ppc-8xx-based machines.

is there any 8xx board left which isn't ported to ARCH=powerpc?

Thanks,
Jochen 

^ permalink raw reply

* [PATCH 1/1] [PPC] 8xx swap bug-fix
From: Yuri Tikhonov @ 2008-02-02  7:47 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20080201181003.a3daf6ed.kim.phillips@freescale.com>


 Hello,

 Here is the patch which makes Linux-2.6 swap routines operate correctly on
the ppc-8xx-based machines.

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
--
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index eb8d26f..321bda2 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -329,8 +329,18 @@ InstructionTLBMiss:
 	mfspr	r11, SPRN_MD_TWC	/* ....and get the pte address */
 	lwz	r10, 0(r11)	/* Get the pte */
 
+#ifdef CONFIG_SWAP
+	/* do not set the _PAGE_ACCESSED bit of a non-present page */
+	andi.	r11, r10, _PAGE_PRESENT
+	beq	4f
+	ori	r10, r10, _PAGE_ACCESSED
+	mfspr	r11, SPRN_MD_TWC	/* get the pte address again */
+	stw	r10, 0(r11)
+4:
+#else
 	ori	r10, r10, _PAGE_ACCESSED
 	stw	r10, 0(r11)
+#endif
 
 	/* The Linux PTE won't go exactly into the MMU TLB.
 	 * Software indicator bits 21, 22 and 28 must be clear.
@@ -395,8 +405,17 @@ DataStoreTLBMiss:
 	DO_8xx_CPU6(0x3b80, r3)
 	mtspr	SPRN_MD_TWC, r11
 
-	mfspr	r11, SPRN_MD_TWC	/* get the pte address again */
+#ifdef CONFIG_SWAP
+	/* do not set the _PAGE_ACCESSED bit of a non-present page */
+	andi.	r11, r10, _PAGE_PRESENT
+	beq	4f
+	ori	r10, r10, _PAGE_ACCESSED
+4:
+	/* and update pte in table */
+#else
 	ori	r10, r10, _PAGE_ACCESSED
+#endif
+	mfspr	r11, SPRN_MD_TWC	/* get the pte address again */
 	stw	r10, 0(r11)
 
 	/* The Linux PTE won't go exactly into the MMU TLB.
@@ -575,7 +594,16 @@ DataTLBError:
 
 	/* Update 'changed', among others.
 	*/
+#ifdef CONFIG_SWAP
+	ori	r10, r10, _PAGE_DIRTY|_PAGE_HWWRITE
+	/* do not set the _PAGE_ACCESSED bit of a non-present page */
+	andi.	r11, r10, _PAGE_PRESENT
+	beq	4f
+	ori	r10, r10, _PAGE_ACCESSED
+4:
+#else
 	ori	r10, r10, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE
+#endif
 	mfspr	r11, SPRN_MD_TWC		/* Get pte address again */
 	stw	r10, 0(r11)		/* and update pte in table */
 
diff --git a/include/asm-ppc/pgtable.h b/include/asm-ppc/pgtable.h
index c159315..76717ff 100644
--- a/include/asm-ppc/pgtable.h
+++ b/include/asm-ppc/pgtable.h
@@ -341,14 +341,6 @@ extern unsigned long ioremap_bot, ioremap_base;
 #define _PMD_PAGE_MASK	0x000c
 #define _PMD_PAGE_8M	0x000c
 
-/*
- * The 8xx TLB miss handler allegedly sets _PAGE_ACCESSED in the PTE
- * for an address even if _PAGE_PRESENT is not set, as a performance
- * optimization.  This is a bug if you ever want to use swap unless
- * _PAGE_ACCESSED is 2, which it isn't, or unless you have 8xx-specific
- * definitions for __swp_entry etc. below, which would be gross.
- *  -- paulus
- */
 #define _PTE_NONE_MASK _PAGE_ACCESSED
 
 #else /* CONFIG_6xx */

-- 
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com

^ permalink raw reply related

* Re: [RFC][POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
From: Grant Likely @ 2008-02-02  6:59 UTC (permalink / raw)
  To: linuxppc-dev, jwboyer, scottwood, stephen.neuendorffer
In-Reply-To: <20080202065517.12920.20235.stgit@trillian.secretlab.ca>

On 2/1/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> This target produces a flat binary rather than an ELF file,
> fixes the entry point at the beginning of the image, and takes
> a complete device tree with no fixups needed.
>
> Based on 'raw' target written by Scott Wood.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
> index ccaedae..ec57ec9 100644
> --- a/arch/powerpc/boot/io.h
> +++ b/arch/powerpc/boot/io.h
> @@ -99,4 +99,11 @@ static inline void barrier(void)
>         asm volatile("" : : : "memory");
>  }
>
> +static inline void disable_irq(void)
> +{
> +       int dummy;
> +       asm volatile("mfmsr %0; rlwinm %0, %0, 0, ~(1<<15); mtmsr %0" :
> +                    "=r" (dummy) : : "memory");
> +}
> +
>  #endif /* _IO_H */

Oops, ignore this bit.  This is leftover cruft from the original
patch.  I've now removed it.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* [RFC][POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
From: Grant Likely @ 2008-02-02  6:55 UTC (permalink / raw)
  To: linuxppc-dev, jwboyer, scottwood, stephen.neuendorffer

From: Grant Likely <grant.likely@secretlab.ca>

This target produces a flat binary rather than an ELF file,
fixes the entry point at the beginning of the image, and takes
a complete device tree with no fixups needed.

Based on 'raw' target written by Scott Wood.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 arch/powerpc/boot/Makefile         |    9 +++-
 arch/powerpc/boot/io.h             |    7 +++
 arch/powerpc/boot/simpleboot.c     |   88 ++++++++++++++++++++++++++++++++++++
 arch/powerpc/boot/virtex405-head.S |   30 ++++++++++++
 arch/powerpc/boot/wrapper          |    4 ++
 5 files changed, 137 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 836234b..c4156ea 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -40,6 +40,7 @@ $(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
 $(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=440
 $(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
 $(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
+$(obj)/virtex405-head.o: BOOTCFLAGS += -mcpu=405
 
 
 zlib       := inffast.c inflate.c inftrees.c
@@ -64,7 +65,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c
 		cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
 		fixed-head.S ep88xc.c ep405.c \
 		cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
-		cuboot-warp.c cuboot-85xx-cpm2.c
+		cuboot-warp.c cuboot-85xx-cpm2.c simpleboot.c virtex405-head.S
 src-boot := $(src-wlib) $(src-plat) empty.c
 
 src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -306,6 +307,12 @@ $(obj)/uImage: vmlinux $(wrapperbits)
 $(obj)/cuImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
 	$(call if_changed,wrap,cuboot-$*,$(dtstree)/$*.dts)
 
+$(obj)/simpleImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+	$(call if_changed,wrap,simpleboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
+
+$(obj)/simpleImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+	$(call if_changed,wrap,simpleboot-$*,$(dtstree)/$*.dts)
+
 $(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
 	$(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
 
diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
index ccaedae..ec57ec9 100644
--- a/arch/powerpc/boot/io.h
+++ b/arch/powerpc/boot/io.h
@@ -99,4 +99,11 @@ static inline void barrier(void)
 	asm volatile("" : : : "memory");
 }
 
+static inline void disable_irq(void)
+{
+	int dummy;
+	asm volatile("mfmsr %0; rlwinm %0, %0, 0, ~(1<<15); mtmsr %0" :
+	             "=r" (dummy) : : "memory");
+}
+
 #endif /* _IO_H */
diff --git a/arch/powerpc/boot/simpleboot.c b/arch/powerpc/boot/simpleboot.c
new file mode 100644
index 0000000..8c2440d
--- /dev/null
+++ b/arch/powerpc/boot/simpleboot.c
@@ -0,0 +1,88 @@
+/*
+ * The simple platform -- for booting when firmware doesn't supply a device
+ *                        tree or any platform configuration information.
+ *                        All data is extracted from an embedded device tree
+ *                        blob.
+ *
+ * Authors: Scott Wood <scottwood@freescale.com>
+ *          Grant Likely <grant.likely@secretlab.ca>
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2008 Secret Lab Technologies Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "types.h"
+#include "io.h"
+#include "stdio.h"
+#include "libfdt/libfdt.h"
+
+BSS_STACK(16*1024);
+static char initial_heap[8*1024];
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+		   unsigned long r6, unsigned long r7)
+{
+	const u32 *na, *ns, *reg, *timebase;
+	u64 memsize64;
+	int node, size, i;
+
+	/* Allocate initial heap for probing the tree */
+	simple_alloc_init(initial_heap, sizeof(initial_heap), 32, 64);
+
+	/* Make sure FDT blob is sane */
+	if (fdt_check_header(_dtb_start) != 0)
+		fatal("Invalid device tree blob\n");
+
+	/* Find the #address-cells and #size-cells properties */
+	node = fdt_path_offset(_dtb_start, "/");
+	if (node < 0)
+		fatal("Cannot find root node\n");
+	na = fdt_getprop(_dtb_start, node, "#address-cells", &size);
+	if (!na || (size != 4))
+		fatal("Cannot find #address-cells property");
+	ns = fdt_getprop(_dtb_start, node, "#size-cells", &size);
+	if (!ns || (size != 4))
+		fatal("Cannot find #size-cells property");
+
+	/* Find the memory range */
+	node = fdt_node_offset_by_prop_value(_dtb_start, -1, "device_type",
+					     "memory", sizeof("memory"));
+	if (node < 0)
+		fatal("Cannot find memory node\n");
+	reg = fdt_getprop(_dtb_start, node, "reg", &size);
+	if (size < (*na+*ns) * sizeof(u32))
+		fatal("cannot get memory range\n");
+
+	/* Only interested in memory based at 0 */
+	for (i = 0; i < *na; i++)
+		if (*reg++ != 0)
+			fatal("Memory range is not based at address 0\n");
+
+	/* get the memsize and trucate it to under 4G on 32 bit machines */
+	memsize64 = 0;
+	for (i = 0; i < *ns; i++)
+		memsize64 = (memsize64 << 32) | *reg++;
+	if (sizeof(void *) == 4 && memsize64 >= 0x100000000ULL)
+		memsize64 = 0xffffffff;
+
+	/* finally, setup the timebase */
+	node = fdt_node_offset_by_prop_value(_dtb_start, -1, "device_type",
+					     "cpu", sizeof("cpu"));
+	if (!node)
+		fatal("Cannot find cpu node\n");
+	timebase = fdt_getprop(_dtb_start, node, "timebase-frequency", &size);
+	if (timebase && (size == 4))
+		timebase_period_ns = 1000000000 / *timebase;
+
+	/* Now we have the real memory size; reinitialize the heap */
+	simple_alloc_init(_end, memsize64 - (unsigned long)_end, 32, 64);
+
+	/* prepare the device tree and find the console */
+	fdt_init(_dtb_start);
+	serial_console_init();
+}
diff --git a/arch/powerpc/boot/virtex405-head.S b/arch/powerpc/boot/virtex405-head.S
new file mode 100644
index 0000000..3edb13f
--- /dev/null
+++ b/arch/powerpc/boot/virtex405-head.S
@@ -0,0 +1,30 @@
+#include "ppc_asm.h"
+
+	.text
+	.global _zimage_start
+_zimage_start:
+
+	/* PPC errata 213: needed by Virtex-4 FX */
+	mfccr0  0
+	oris    0,0,0x50000000@h
+	mtccr0  0
+
+	/*
+	 * Invalidate the data cache if the data cache is turned off.
+	 * - The 405 core does not invalidate the data cache on power-up
+	 *   or reset but does turn off the data cache. We cannot assume
+	 *   that the cache contents are valid.
+	 * - If the data cache is turned on this must have been done by
+	 *   a bootloader and we assume that the cache contents are
+	 *   valid.
+	 */
+	mfdccr	r9
+	cmplwi	r9,0
+	bne	2f
+	lis	r9,0
+	li	r8,256
+	mtctr	r8
+1:	dccci	r0,r9
+	addi	r9,r9,0x20
+	bdnz	1b
+2:	b	_zimage_start_lib
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index c317815..1f41ff4 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -195,6 +195,10 @@ ep88xc|ep405|redboot*|ep8248e)
     platformo="$object/fixed-head.o $object/$platform.o"
     binary=y
     ;;
+simpleboot-virtex405-*)
+    platformo="$object/virtex405-head.o $object/simpleboot.o"
+    binary=y
+    ;;
 esac
 
 vmz="$tmpdir/`basename \"$kernel\"`.$ext"

^ permalink raw reply related

* Re: [PATCH 4/5] ehea: fix phyp checkpatch complaints
From: Doug Maxey @ 2008-02-02  4:39 UTC (permalink / raw)
  To: Scott Wood
  Cc: Jan-Bernd Themann, netdev, Jeff Garzik, Linux PowerPC List,
	Paul Mackerras
In-Reply-To: <20080201192344.GA4541@loki.buserror.net>


On Fri, 01 Feb 2008 13:23:45 CST, Scott Wood wrote:
> On Thu, Jan 31, 2008 at 08:20:50PM -0600, Doug Maxey wrote:
> >  /* input param R5 */
> > -#define H_ALL_RES_QP_EQPO         EHEA_BMASK_IBM(9, 11)
...
> > +#define H_ALL_RES_QP_EQPO	  EHEA_BMASK_IBM(9, 11)
...
> 
> This was better the way it was (before, it was readable at any tab setting);
> checkpatch is overeager to complain on tab/space issues (it's a bit hard to
> distinguish indentation from alignment with a regex).

In emacs, with no special offsets, the lines appear to still line up.

What did happen was spaces were turned to tabs where applicable.

What editor shows a bad alignment?

++doug

^ permalink raw reply

* Re: pthread / TQM5200 problem
From: Wolfgang Denk @ 2008-02-02  4:24 UTC (permalink / raw)
  To: Sebastian Theiss; +Cc: linuxppc-dev
In-Reply-To: <002c01c864d0$a4ad11c0$0101a8c0@tis>

In message <002c01c864d0$a4ad11c0$0101a8c0@tis> you wrote:
> 
> I've been having some headache using the pthread library with a TB5200 box
> (based on a TQM5200 board with a Freescale MPC5200 PowerPC-CPU). I created a
> small program to pin down the problem and it runs fine on all my Unix- and

NOTE: It is really bad behaviour to post the same  question  indepen-
dently  in  several  mailing  list.  Your  question  has already been
answered on the ELDK list.

> Linux-machines but fails on the embedded box: The program contains a class
> CSignal that provides thread-synchronisation based on the
> pthread_cond_signal and pthread_cond_wait calls and takes care of the
> "spurious wakeup" and "lost signal" problems. The program runs 159
> additional threads (that seems to be some internal limit), each of them

And this strange "internal limit"  is  an  indication  that  you  are
running code that is more than 1.5 years old, as the bug was fixed in
September  2006.  It was caused by bad PCI mappings that overlap with
CONFIG_TASKSIZE.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It would seem that evil retreats when forcibly confronted
	-- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5

^ permalink raw reply

* RE: build is broken
From: Bizhan Gholikhamseh (bgholikh) @ 2008-02-02  4:22 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080201212408.1bdf4acd@zod.rchland.ibm.com>


> -----Original Message-----
> From: Josh Boyer [mailto:jwboyer@gmail.com]=20
> Sent: Friday, February 01, 2008 7:24 PM
> To: Bizhan Gholikhamseh (bgholikh)
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: build is broken
>=20
> On Fri, 1 Feb 2008 15:23:21 -0800
> "Bizhan Gholikhamseh (bgholikh)" <bgholikh@cisco.com> wrote:
>=20
> > Hi
> > I just downloaded the latest source tree from :
> > git://www.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
> >=20
> > I am using gnu cross compiler version 3.4.3. I get the an "awk" and=20
> > "assmbeler" error.
> >=20
> > Please help me out. Thanks
> >=20
> > $ <mailto:bizhan@PPC]$>  make ARCH=3Dpowerpc
> > CROSS_COMPILE=3Dpowerpc-linux-gnu- uImage
> > awk: cmd. line:1: (FILENAME=3D- FNR=3D2) fatal: attempt to=20
> access field -1
> >   CHK     include/linux/version.h
> >   CHK     include/linux/utsrelease.h
> >   CALL    scripts/checksyscalls.sh
> >   CHK     include/linux/compile.h
> >   CALL    arch/powerpc/kernel/systbl_chk.sh
> >   LD      vmlinux.o
> >   MODPOST vmlinux.o
> > WARNING: vmlinux.o(.meminit.text+0x9f8): Section mismatch=20
> in reference=20
> > from the function free_area_init_node() to the function
> > .init.text:__alloc_bootmem_node()
> > The function __meminit free_area_init_node() references a function=20
> > __init __alloc_bootmem_node().
> > If free_area_init_node is only used by __alloc_bootmem_node then=20
> > annotate free_area_init_node with a matching annotation.
> > =20
> >   AS      .tmp_kallsyms2.o
> >   LD      vmlinux
> >   SYSMAP  System.map
> >   SYSMAP  .tmp_System.map
> >   BOOTCC  arch/powerpc/boot/treeboot-walnut.o
> > Assembler messages:
> > Error: Internal assembler error for instruction icbt=20
> Internal error,=20
> > aborting at=20
> >=20
> /usr/src/RPM/BUILD/crosstool/source/binutils-2.15/gas/config/tc-ppc.c
> > line 1300 in ppc_setup_opcodes
> > Please report this bug.
> > make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
> > make: *** [uImage] Error 2
>=20
> I have no idea why you would get that if you have a properly=20
> built toolchain.  Can you do a fresh compile with V=3D1 set?
>=20
> josh
>
I did the fresh build with V=3D1. I still get the same awk error and the
compile's last line output:
  powerpc-linux-gnuspe-gcc -m32
-Wp,-MD,arch/powerpc/boot/.treeboot-walnut.o.d -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -msoft-float
-pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc -isystem
/opt/Embedix/usr/local/powerpc-linux-gnuspe/gcc-3.4.3-e500-glibc-2.3.3-s
pe/lib/gcc/powerpc-linux-gnuspe/3.4.3/include -Iarch/powerpc/boot
-I/home/bizhan/PPC/arch/powerpc/boot
-I/home/bizhan/PPC/arch/powerpc/boot/libfdt -mcpu=3D405 -c -o
arch/powerpc/boot/treeboot-walnut.o arch/powerpc/boot/treeboot-walnut.c
Assembler messages:
Error: Internal assembler error for instruction icbt
Internal error, aborting at
/usr/src/RPM/BUILD/crosstool/source/binutils-2.15/gas/config/tc-ppc.c
line 1300 in ppc_setup_opcodes
Please report this bug.
make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
make: *** [uImage] Error 2

Any help greatly apprieciated.

Thanks,
Bizhan

^ permalink raw reply

* Re: build is broken
From: Josh Boyer @ 2008-02-02  3:24 UTC (permalink / raw)
  To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1AA28@xmb-sjc-212.amer.cisco.com>

On Fri, 1 Feb 2008 15:23:21 -0800
"Bizhan Gholikhamseh (bgholikh)" <bgholikh@cisco.com> wrote:

> Hi 
> I just downloaded the latest source tree from :
> git://www.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
> 
> I am using gnu cross compiler version 3.4.3. I get the an "awk" and
> "assmbeler" error.
> 
> Please help me out. Thanks
> 
> $ <mailto:bizhan@PPC]$>  make ARCH=powerpc
> CROSS_COMPILE=powerpc-linux-gnu- uImage
> awk: cmd. line:1: (FILENAME=- FNR=2) fatal: attempt to access field -1
>   CHK     include/linux/version.h
>   CHK     include/linux/utsrelease.h
>   CALL    scripts/checksyscalls.sh
>   CHK     include/linux/compile.h
>   CALL    arch/powerpc/kernel/systbl_chk.sh
>   LD      vmlinux.o
>   MODPOST vmlinux.o
> WARNING: vmlinux.o(.meminit.text+0x9f8): Section mismatch in reference
> from the function free_area_init_node() to the function
> .init.text:__alloc_bootmem_node()
> The function __meminit free_area_init_node() references
> a function __init __alloc_bootmem_node().
> If free_area_init_node is only used by __alloc_bootmem_node then
> annotate free_area_init_node with a matching annotation.
>  
>   AS      .tmp_kallsyms2.o
>   LD      vmlinux
>   SYSMAP  System.map
>   SYSMAP  .tmp_System.map
>   BOOTCC  arch/powerpc/boot/treeboot-walnut.o
> Assembler messages:
> Error: Internal assembler error for instruction icbt
> Internal error, aborting at
> /usr/src/RPM/BUILD/crosstool/source/binutils-2.15/gas/config/tc-ppc.c
> line 1300 in ppc_setup_opcodes
> Please report this bug.
> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
> make: *** [uImage] Error 2

I have no idea why you would get that if you have a properly built
toolchain.  Can you do a fresh compile with V=1 set?

josh

^ permalink raw reply

* [PATCH 3/3] powerpc: mpc83xx_defconfig: enable math emulation and ucc_geth
From: Kim Phillips @ 2008-02-02  0:10 UTC (permalink / raw)
  To: linuxppc-dev

and some PHYs mpc83xx boards use.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
 arch/powerpc/configs/mpc83xx_defconfig |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/configs/mpc83xx_defconfig b/arch/powerpc/configs/mpc83xx_defconfig
index 31bdbf3..a9807f0 100644
--- a/arch/powerpc/configs/mpc83xx_defconfig
+++ b/arch/powerpc/configs/mpc83xx_defconfig
@@ -186,7 +186,7 @@ CONFIG_PREEMPT_NONE=y
 # CONFIG_PREEMPT is not set
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_MATH_EMULATION is not set
+CONFIG_MATH_EMULATION=y
 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
 CONFIG_ARCH_FLATMEM_ENABLE=y
 CONFIG_ARCH_POPULATES_NODE_MAP=y
@@ -416,14 +416,14 @@ CONFIG_PHYLIB=y
 # MII PHY device drivers
 #
 CONFIG_MARVELL_PHY=y
-# CONFIG_DAVICOM_PHY is not set
+CONFIG_DAVICOM_PHY=y
 # CONFIG_QSEMI_PHY is not set
 # CONFIG_LXT_PHY is not set
 # CONFIG_CICADA_PHY is not set
-# CONFIG_VITESSE_PHY is not set
+CONFIG_VITESSE_PHY=y
 # CONFIG_SMSC_PHY is not set
 # CONFIG_BROADCOM_PHY is not set
-# CONFIG_ICPLUS_PHY is not set
+CONFIG_ICPLUS_PHY=y
 # CONFIG_FIXED_PHY is not set
 # CONFIG_MDIO_BITBANG is not set
 CONFIG_NET_ETHERNET=y
@@ -436,7 +436,7 @@ CONFIG_MII=y
 CONFIG_NETDEV_1000=y
 CONFIG_GIANFAR=y
 # CONFIG_GFAR_NAPI is not set
-# CONFIG_UCC_GETH is not set
+CONFIG_UCC_GETH=y
 CONFIG_NETDEV_10000=y
 
 #
-- 
1.5.2.2

^ permalink raw reply related

* [PATCH 2/3] powerpc: fsl_soc: fix mpc83xx_spi device registration
From: Kim Phillips @ 2008-02-02  0:09 UTC (permalink / raw)
  To: linuxppc-dev

calling platform_device_register after platform_device_alloc causes
this:

kobject (c3841a70): tried to init an initialized object, something is seriously wrong.
Call Trace:
[c381fe20] [c0007bb8] show_stack+0x3c/0x194 (unreliable)
[c381fe50] [c01322a8] kobject_init+0xb8/0xbc
[c381fe60] [c01591cc] device_initialize+0x30/0x9c
[c381fe80] [c015ee34] platform_device_register+0x1c/0x34
[c381fea0] [c02f1fe0] of_fsl_spi_probe+0x21c/0x22c
[c381ff30] [c02f2044] fsl_spi_init+0x54/0x160
[c381ff60] [c02f3924] __machine_initcall_mpc832x_rdb_mpc832x_spi_init+0x120/0x138
[c381ff70] [c02e61b4] kernel_init+0x98/0x284
[c381fff0] [c000f740] kernel_thread+0x44/0x60

fixed by calling platform_device_add (second half of
platform_device_register) instead.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
 arch/powerpc/sysdev/fsl_soc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index e48b20e..2c5388c 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -1342,7 +1342,7 @@ static int __init of_fsl_spi_probe(char *type, char *compatible, u32 sysclk,
 		if (ret)
 			goto unreg;
 
-		ret = platform_device_register(pdev);
+		ret = platform_device_add(pdev);
 		if (ret)
 			goto unreg;
 
-- 
1.5.2.2

^ permalink raw reply related

* [PATCH 1/3] powerpc: mpc832x_rdb: fix compiler warning
From: Kim Phillips @ 2008-02-02  0:09 UTC (permalink / raw)
  To: linuxppc-dev

arch/powerpc/platforms/83xx/mpc832x_rdb.c: In function ‘mpc832x_rdb_setup_arch’:
arch/powerpc/platforms/83xx/mpc832x_rdb.c:104: warning: ‘np’ is used uninitialized in this function

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
 arch/powerpc/platforms/83xx/mpc832x_rdb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index 9f0fd88..e7f706b 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -101,7 +101,7 @@ static void __init mpc832x_rdb_setup_arch(void)
 #ifdef CONFIG_QUICC_ENGINE
 	qe_reset();
 
-	if ((np = of_find_node_by_name(np, "par_io")) != NULL) {
+	if ((np = of_find_node_by_name(NULL, "par_io")) != NULL) {
 		par_io_init(np);
 		of_node_put(np);
 
-- 
1.5.2.2

^ permalink raw reply related

* Re: [PATCH 1/2] pci: Fix bus resource assignment on 32 bits with 64b resources
From: Greg KH @ 2008-02-01 23:34 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linux-pci, linux-kernel, linuxppc-dev
In-Reply-To: <200802011118.57610.sr@denx.de>

On Fri, Feb 01, 2008 at 11:18:56AM +0100, Stefan Roese wrote:
> On Monday 10 December 2007, Benjamin Herrenschmidt wrote:
> > The current pci_assign_unassigned_resources() code doesn't work properly
> > on 32 bits platforms with 64 bits resources. The main reason is the use
> > of unsigned long in various places instead of resource_size_t.
> >
> > This fixes it, along with some tricks to avoid casting to 64 bits on
> > platforms that don't need it in every printk around.
> >
> > This is a pre-requisite for making powerpc use the generic code instead of
> > its own half-useful implementation.
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> 
> Checking Linus's latest git repository, it seems this patch (and the 2nd from 
> this series) hasn't been applied till now. This is just a reminder, that it 
> gets in in this merge-window.

Just got sent to him...

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH] [POWERPC] fsl_soc: add support for "fsl, immr" compatible matching
From: Anton Vorontsov @ 2008-02-01 23:30 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47A38C49.7020606@freescale.com>

On Fri, Feb 01, 2008 at 03:16:57PM -0600, Scott Wood wrote:
> Anton Vorontsov wrote:
> > -	soc8540@e0000000 {
> > +	soc@e0000000 {
> >  		#address-cells = <1>;
> >  		#size-cells = <1>;
> >  		#interrupt-cells = <2>;
> > -		device_type = "soc";
> > +		compatible = "fsl,mpc8540-immr", "fsl,immr", "simple-bus";
> >  		ranges = <00000000 e0000000 00100000>
> >  		reg = <e0000000 00003000>;
> >  		bus-frequency = <0>;
> 
> It's called "CCSR" rather than "IMMR" on 85xx.

^^ Theory.

$ grep ccsr -r arch/powerpc/boot/dts/
$

$ grep immr -r arch/powerpc/boot/dts/ | grep 85 | cut -d: -f1
arch/powerpc/boot/dts/tqm8540.dts
arch/powerpc/boot/dts/tqm8541.dts
arch/powerpc/boot/dts/mpc8572ds.dts
arch/powerpc/boot/dts/tqm8555.dts
arch/powerpc/boot/dts/stx_gp3_8560.dts
arch/powerpc/boot/dts/mpc885ads.dts
arch/powerpc/boot/dts/tqm8560.dts

^^ Practice. :-)


Maybe "fsl,soc", finally? :-) I think soc, ccsr or immr doesn't
really matter, what really matters is consistency. <cpu-specific>
part of the -ccsr/-immr should be sufficient to distinct whether
we're on 85xx or 83xx...

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2

^ permalink raw reply

* build is broken
From: Bizhan Gholikhamseh (bgholikh) @ 2008-02-01 23:23 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

Hi 
I just downloaded the latest source tree from :
git://www.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git

I am using gnu cross compiler version 3.4.3. I get the an "awk" and
"assmbeler" error.

Please help me out. Thanks

$ <mailto:bizhan@PPC]$>  make ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu- uImage
awk: cmd. line:1: (FILENAME=- FNR=2) fatal: attempt to access field -1
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CHK     include/linux/compile.h
  CALL    arch/powerpc/kernel/systbl_chk.sh
  LD      vmlinux.o
  MODPOST vmlinux.o
WARNING: vmlinux.o(.meminit.text+0x9f8): Section mismatch in reference
from the function free_area_init_node() to the function
.init.text:__alloc_bootmem_node()
The function __meminit free_area_init_node() references
a function __init __alloc_bootmem_node().
If free_area_init_node is only used by __alloc_bootmem_node then
annotate free_area_init_node with a matching annotation.
 
  AS      .tmp_kallsyms2.o
  LD      vmlinux
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  BOOTCC  arch/powerpc/boot/treeboot-walnut.o
Assembler messages:
Error: Internal assembler error for instruction icbt
Internal error, aborting at
/usr/src/RPM/BUILD/crosstool/source/binutils-2.15/gas/config/tc-ppc.c
line 1300 in ppc_setup_opcodes
Please report this bug.
make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
make: *** [uImage] Error 2


[-- Attachment #2: Type: text/html, Size: 2626 bytes --]

^ permalink raw reply

* Re: 8360 custom board, ucc_geth TX errors on longer(?) packets
From: Kim Phillips @ 2008-02-01 23:18 UTC (permalink / raw)
  To: Steven Hein; +Cc: linuxppc-embedded
In-Reply-To: <47A397D7.30809@sgi.com>

On Fri, 01 Feb 2008 16:06:15 -0600
Steven Hein <ssh@sgi.com> wrote:

> Steven Hein wrote:
> > But we're using GMII to the switch....and that workaround
> > code wasn't in active in my old kernel (it was there, but
> > commented out).
> >
> > Any other thoughts?    Has anyone seen this symptom before?
> >
> > Steve
> >
> Okay....I found it!    Started poking at the UCCE registers
> and found that the FIFO sizes weren't right.   This led me
> to find a bug in my ucc_geth interface to the fixed-link
> PHY driver:  the code to reconfigure the MURAM FIFO's for
> Gigabit operation wasn't being executed for no-phy configs!
> All is well once I changed this.
> 
> Sorry for the noise.....   (glad I found this before
> submitting my patch!   ;-)
> 
yeah ucc_geth should be made aware of fixed-links on startup; UCCs
aren't like TSECs that know what MII type they're on.

setting phy-connection-type to certain strings containing a
'g' in the device tree should do the trick, too..:)

Kim

^ permalink raw reply

* Enabling MSR debugging mode on MPC8541cds
From: Bizhan Gholikhamseh (bgholikh) @ 2008-02-01 22:17 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Hi All,
I am working on powerpc git tree version
Linux-2.6.22-rc4-geff2ebd2-dirty.
Our custom board is based on mpc8541cds. I am trying to use Jtag to
debug
the kernel issues. I have done the following changes to the source tree:
 
On the top directory Makefile:
 
CC                = $(CROSS_COMPILE)gcc -g2 -gdwarf-2
AFLAG_KERNEL = -Wa,gdwarf2
 
include/asm-powerpc/reg_booke.h:
/* Default MSR for kernel mode. */ 
#if defined (CONFIG_40x) 
#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR|MSR_CE|MSR_DE)  
#elif defined(CONFIG_BOOKE) 
#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE|MSR_DE)
 
However, I can see through Jtag that the MSR_DE (the debug bit) is not
set on the, 
so I am not able to set break points.
 
Any help greatly appreciated.
 
Regards,
Bizhan

[-- Attachment #2: Type: text/html, Size: 6215 bytes --]

^ permalink raw reply

* Re: 8360 custom board, ucc_geth TX errors on longer(?) packets
From: Steven Hein @ 2008-02-01 22:06 UTC (permalink / raw)
  Cc: linuxppc-embedded
In-Reply-To: <47A37B8E.5000500@sgi.com>

Steven Hein wrote:
> Kim Phillips wrote:
>> On Fri, 01 Feb 2008 12:52:25 -0600
>> Steven Hein <ssh@sgi.com> wrote:
>>
>>  
>>> The one main difference in this board is how eth0 is wired.
>>> We have a Broadcom GbE switch part, and UCC1 eth is wired
>>> directly to that switch (no PHY).   (This where I needed to
>>>     
>>
>> sounds like you ran into some h/w errata.  if on rgmii, you might
>> want to find a way to program the switch for rgmii with internal delay
>> (8360 rev.2 rgmii-id rx & tx; 8360rev2.1 rgmii-rxid (i.e. for rx
>> only)).  If not, I'd contact fsl tech support directly.
>>
>> Kim
>>   
>
> I would suspect HW.....but this WORKS with the 2.6.16 kernel
> I was using!    That's why I suspect that I still don't have
> something configured right in my device tree, or something
> else I missed in the new kernel.    But I can't
> figure out what it is.... :-(    I've poured over the code in
> the old versus new (both the ucc_geth driver and the platform
> initialization in the old, and the device tree in the new)
> and can't figure out what I missed!   And like I said, a
> kernel with the same config (other than changing the platform)
> works on my MPC8360E-MDS board.   Granted, that doesn't have
> this direct switch connection......
>
> I did look at the code related to the HW errata (QE_ENET18).
> But we're using GMII to the switch....and that workaround
> code wasn't in active in my old kernel (it was there, but
> commented out).
>
> Any other thoughts?    Has anyone seen this symptom before?
>
> Steve
>
Okay....I found it!    Started poking at the UCCE registers
and found that the FIFO sizes weren't right.   This led me
to find a bug in my ucc_geth interface to the fixed-link
PHY driver:  the code to reconfigure the MURAM FIFO's for
Gigabit operation wasn't being executed for no-phy configs!
All is well once I changed this.

Sorry for the noise.....   (glad I found this before
submitting my patch!   ;-)

Steve

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.                          
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

^ permalink raw reply

* Re: [patch v6 2/4] USB: add Cypress c67x00 OTG controller core driver
From: David Brownell @ 2008-02-01 21:58 UTC (permalink / raw)
  To: Peter Korsgaard; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <20080129123119.681862000@sunsite.dk>

On Tuesday 29 January 2008, Peter Korsgaard wrote:
> This patch add the core driver for the c67x00 USB OTG controller.  The core
> driver is responsible for the platform bus binding and creating either
> USB HCD or USB Gadget instances for each of the serial interface engines
> on the chip.
>     
> This driver does not directly implement the HCD or gadget behaviours; it
> just controls access to the chip.
>     
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

Acked-by: David Brownell <dbrownell@users.sourceforge.net>

> ---
>  MAINTAINERS                     |    6 +
>  drivers/usb/c67x00/c67x00-drv.c |  232 ++++++++++++++++++++++++++++++++++++++++
>  include/linux/usb/c67x00.h      |   48 ++++++++
>  3 files changed, 286 insertions(+)
> 
> Index: linux-2.6/drivers/usb/c67x00/c67x00-drv.c
> ===================================================================
> --- /dev/null
> +++ linux-2.6/drivers/usb/c67x00/c67x00-drv.c
> @@ -0,0 +1,232 @@
> +/*
> + * c67x00-drv.c: Cypress C67X00 USB Common infrastructure
> + *
> + * Copyright (C) 2006-2008 Barco N.V.
> + *    Derived from the Cypress cy7c67200/300 ezusb linux driver and
> + *    based on multiple host controller drivers inside the linux kernel.
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA  02110-1301  USA.
> + */
> +
> +/*
> + * This file implements the common infrastructure for using the c67x00.
> + * It is both the link between the platform configuration and subdrivers and
> + * the link between the common hardware parts and the subdrivers (e.g.
> + * interrupt handling).
> + *
> + * The c67x00 has 2 SIE's (serial interface engine) wich can be configured
> + * to be host, device or OTG (with some limitations, E.G. only SIE1 can be OTG).
> + *
> + * Depending on the platform configuration, the SIE's are created and
> + * the corresponding subdriver is initialized (c67x00_probe_sie).
> + */
> +
> +#include <linux/device.h>
> +#include <linux/list.h>
> +#include <linux/usb.h>
> +#include <linux/usb/c67x00.h>
> +#include <asm/io.h>
> +
> +#include "c67x00.h"
> +
> +static void c67x00_probe_sie(struct c67x00_sie *sie,
> +			     struct c67x00_device *dev, int sie_num)
> +{
> +	spin_lock_init(&sie->lock);
> +	sie->dev = dev;
> +	sie->sie_num = sie_num;
> +	sie->mode = c67x00_sie_config(dev->pdata->sie_config, sie_num);
> +
> +	switch (sie->mode) {
> +	case C67X00_SIE_UNUSED:
> +		dev_info(sie_dev(sie),
> +			 "Not using SIE %d as requested\n", sie->sie_num);
> +		break;
> +
> +	default:
> +		dev_err(sie_dev(sie),
> +			"Unsupported configuration: 0x%x for SIE %d\n",
> +			sie->mode, sie->sie_num);
> +		break;
> +	}
> +}
> +
> +static void c67x00_remove_sie(struct c67x00_sie *sie)
> +{
> +}
> +
> +static irqreturn_t c67x00_irq(int irq, void *__dev)
> +{
> +	struct c67x00_device *c67x00 = __dev;
> +	struct c67x00_sie *sie;
> +	u16 msg, int_status;
> +	int i, count = 8;
> +
> +	int_status = c67x00_ll_hpi_status(c67x00);
> +	if (!int_status)
> +		return IRQ_NONE;
> +
> +	while (int_status != 0 && (count-- >= 0)) {
> +		c67x00_ll_irq(c67x00, int_status);
> +		for (i = 0; i < C67X00_SIES; i++) {
> +			sie = &c67x00->sie[i];
> +			msg = 0;
> +			if (int_status & SIEMSG_FLG(i))
> +				msg = c67x00_ll_fetch_siemsg(c67x00, i);
> +			if (sie->irq)
> +				sie->irq(sie, int_status, msg);
> +		}
> +		int_status = c67x00_ll_hpi_status(c67x00);
> +	}
> +
> +	if (int_status)
> +		dev_warn(&c67x00->pdev->dev, "Not all interrupts handled! "
> +			 "status = 0x%04x\n", int_status);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +/* ------------------------------------------------------------------------- */
> +
> +static int __devinit c67x00_drv_probe(struct platform_device *pdev)
> +{
> +	struct c67x00_device *c67x00;
> +	struct c67x00_platform_data *pdata;
> +	struct resource *res, *res2;
> +	int ret, i;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res)
> +		return -ENODEV;
> +
> +	res2 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +	if (!res2)
> +		return -ENODEV;
> +
> +	pdata = pdev->dev.platform_data;
> +	if (!pdata)
> +		return -ENODEV;
> +
> +	c67x00 = kzalloc(sizeof(*c67x00), GFP_KERNEL);
> +	if (!c67x00)
> +		return -ENOMEM;
> +
> +	if (!request_mem_region(res->start, res->end - res->start + 1,
> +				pdev->name)) {
> +		dev_err(&pdev->dev, "Memory region busy\n");
> +		ret = -EBUSY;
> +		goto request_mem_failed;
> +	}
> +	c67x00->hpi.base = ioremap(res->start, res->end - res->start + 1);
> +	if (!c67x00->hpi.base) {
> +		dev_err(&pdev->dev, "Unable to map HPI registers\n");
> +		ret = -EIO;
> +		goto map_failed;
> +	}
> +
> +	spin_lock_init(&c67x00->hpi.lock);
> +	c67x00->hpi.regstep = pdata->hpi_regstep;
> +	c67x00->pdata = pdev->dev.platform_data;
> +	c67x00->pdev = pdev;
> +
> +	c67x00_ll_init(c67x00);
> +	c67x00_ll_hpi_reg_init(c67x00);
> +
> +	ret = request_irq(res2->start, c67x00_irq, 0, pdev->name, c67x00);
> +	if (ret) {
> +		dev_err(&pdev->dev, "Cannot claim IRQ\n");
> +		goto request_irq_failed;
> +	}
> +
> +	ret = c67x00_ll_reset(c67x00);
> +	if (ret) {
> +		dev_err(&pdev->dev, "Device reset failed\n");
> +		goto reset_failed;
> +	}
> +
> +	for (i = 0; i < C67X00_SIES; i++)
> +		c67x00_probe_sie(&c67x00->sie[i], c67x00, i);
> +
> +	platform_set_drvdata(pdev, c67x00);
> +
> +	return 0;
> +
> + reset_failed:
> +	free_irq(res2->start, c67x00);
> + request_irq_failed:
> +	iounmap(c67x00->hpi.base);
> + map_failed:
> +	release_mem_region(res->start, res->end - res->start + 1);
> + request_mem_failed:
> +	kfree(c67x00);
> +
> +	return ret;
> +}
> +
> +static int __devexit c67x00_drv_remove(struct platform_device *pdev)
> +{
> +	struct c67x00_device *c67x00 = platform_get_drvdata(pdev);
> +	struct resource *res;
> +	int i;
> +
> +	for (i = 0; i < C67X00_SIES; i++)
> +		c67x00_remove_sie(&c67x00->sie[i]);
> +
> +	c67x00_ll_release(c67x00);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +	if (res)
> +		free_irq(res->start, c67x00);
> +
> +	iounmap(c67x00->hpi.base);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (res)
> +		release_mem_region(res->start, res->end - res->start + 1);
> +
> +	kfree(c67x00);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver c67x00_driver = {
> +	.probe	= c67x00_drv_probe,
> +	.remove	= __devexit_p(c67x00_drv_remove),
> +	.driver	= {
> +		.owner = THIS_MODULE,
> +		.name = "c67x00",
> +	},
> +};
> +
> +static int __init c67x00_init(void)
> +{
> +	if (usb_disabled())
> +		return -ENODEV;
> +
> +	return platform_driver_register(&c67x00_driver);
> +}
> +
> +static void __exit c67x00_exit(void)
> +{
> +	platform_driver_unregister(&c67x00_driver);
> +}
> +
> +module_init(c67x00_init);
> +module_exit(c67x00_exit);
> +
> +MODULE_AUTHOR("Peter Korsgaard, Jan Veldeman, Grant Likely");
> +MODULE_DESCRIPTION("Cypress C67X00 USB Controller Driver");
> +MODULE_LICENSE("GPL");
> Index: linux-2.6/include/linux/usb/c67x00.h
> ===================================================================
> --- /dev/null
> +++ linux-2.6/include/linux/usb/c67x00.h
> @@ -0,0 +1,48 @@
> +/*
> + * usb_c67x00.h: platform definitions for the Cypress C67X00 USB chip
> + *
> + * Copyright (C) 2006-2008 Barco N.V.
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA  02110-1301  USA.
> + */
> +
> +#ifndef _LINUX_USB_C67X00_H
> +#define _LINUX_USB_C67X00_H
> +
> +/* SIE configuration */
> +#define C67X00_SIE_UNUSED	0
> +#define C67X00_SIE_HOST		1
> +#define C67X00_SIE_PERIPHERAL_A	2	/* peripheral on A port */
> +#define C67X00_SIE_PERIPHERAL_B	3	/* peripheral on B port */
> +
> +#define c67x00_sie_config(config, n)  (((config)>>(4*(n)))&0x3)
> +
> +#define C67X00_SIE1_UNUSED	        (C67X00_SIE_UNUSED		<< 0)
> +#define C67X00_SIE1_HOST	        (C67X00_SIE_HOST		<< 0)
> +#define C67X00_SIE1_PERIPHERAL_A	(C67X00_SIE_PERIPHERAL_A	<< 0)
> +#define C67X00_SIE1_PERIPHERAL_B	(C67X00_SIE_PERIPHERAL_B	<< 0)
> +
> + #define C67X00_SIE2_UNUSED	        (C67X00_SIE_UNUSED		<< 4)
> + #define C67X00_SIE2_HOST	        (C67X00_SIE_HOST		<< 4)
> + #define C67X00_SIE2_PERIPHERAL_A	(C67X00_SIE_PERIPHERAL_A	<< 4)
> + #define C67X00_SIE2_PERIPHERAL_B	(C67X00_SIE_PERIPHERAL_B	<< 4)
> +
> +struct c67x00_platform_data {
> +	int sie_config;			/* SIEs config (C67X00_SIEx_*) */
> +	unsigned long hpi_regstep;	/* Step between HPI registers  */
> +};
> +
> +#endif /* _LINUX_USB_C67X00_H */
> Index: linux-2.6/MAINTAINERS
> ===================================================================
> --- linux-2.6.orig/MAINTAINERS
> +++ linux-2.6/MAINTAINERS
> @@ -3841,6 +3841,12 @@
>  S:	Maintained
>  W:	http://www.kroah.com/linux-usb/
>  
> +USB CYPRESS C67X00 DRIVER
> +P:	Peter Korsgaard
> +M:	jacmet@sunsite.dk
> +L:	linux-usb@vger.kernel.org
> +S:	Maintained
> +
>  USB DAVICOM DM9601 DRIVER
>  P:	Peter Korsgaard
>  M:	jacmet@sunsite.dk
> 
> --
> Bye, Peter Korsgaard
> 

^ permalink raw reply

* Re: [patch v6 1/4] USB: add Cypress c67x00 low level interface code
From: David Brownell @ 2008-02-01 21:54 UTC (permalink / raw)
  To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell, linux-usb
In-Reply-To: <20080129123119.273749000@sunsite.dk>

On Tuesday 29 January 2008, Peter Korsgaard wrote:
> This patch adds the low level support code for the Cypress c67x00 family of
> OTG controllers.  The low level code is responsible for register access and
> implements the software protocol for communicating with the 16bit
> microcontroller inside the c67x00 device.
> 
> Communication is done over the HPI interface (16bit SRAM-like parallel bus).
>     
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

If you fix the issues I note below:

Acked-by: David Brownell <dbrownell@users.sourceforge.net>



> +/**
> + * struct c67x00_sie - Common data associated with a SIE
> + * @lock: lock to protect this struct

"and the associated chip registers"

> + * @private_data: subdriver dependent data
> + * @irq: subdriver dependent irq handler, set NULL when not used
> + * @dev: link to common driver structure
> + * @sie_num: SIE number on chip, starting from 0
> + * @mode: SIE mode (host/peripheral/otg/not used)
> + */
> +struct c67x00_sie {
> +	/* Entries to be used by the subdrivers */
> +	spinlock_t lock;	/* protect this structure */
> +	void *private_data;
> +	void (*irq) (struct c67x00_sie *sie, u16 int_status, u16 msg);
> +
> +	/* Read only: */
> +	struct c67x00_device *dev;
> +	int sie_num;
> +	int mode;
> +};


In the C file:

> +static inline u16 hpi_read_word(struct c67x00_device *dev, u16 reg)
> +{
> +	u16 value;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&dev->hpi.lock, flags);
> +	value = hpi_read_word_nolock(dev, reg);
> +	spin_unlock_irqrestore(&dev->hpi.lock, flags);
> +
> +	return value;
> +}
> +
> +static inline void hpi_write_word_nolock(struct c67x00_device *dev, u16 reg,
> +					 u16 value)
> +{
> +	hpi_write_reg(dev, HPI_ADDR, reg);
> +	hpi_write_reg(dev, HPI_DATA, value);
> +}
> +
> +static inline void hpi_write_word(struct c67x00_device *dev, u16 reg, u16 value)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&dev->hpi.lock, flags);
> +	hpi_write_word_nolock(dev, reg, value);
> +	spin_unlock_irqrestore(&dev->hpi.lock, flags);
> +}
> +
> +/*
> + * Only data is little endian, addr has cpu endianess
> + */
> +static inline void hpi_write_words_le16(struct c67x00_device *dev, u16 addr,
> +					u16 *data, u16 count)
> +{
> +	unsigned long flags;
> +	int i;
> +
> +	spin_lock_irqsave(&dev->hpi.lock, flags);
> +
> +	hpi_write_reg(dev, HPI_ADDR, addr);
> +	for (i = 0; i < count; i++)
> +		hpi_write_reg(dev, HPI_DATA, cpu_to_le16(*data++));
> +
> +	spin_unlock_irqrestore(&dev->hpi.lock, flags);
> +}
> +
> +/*
> + * Only data is little endian, addr has cpu endianess
> + */
> +static inline void hpi_read_words_le16(struct c67x00_device *dev, u16 addr,
> +				       u16 *data, u16 count)
> +{
> +	unsigned long flags;
> +	int i;
> +	spin_lock_irqsave(&dev->hpi.lock, flags);
> +	hpi_write_reg(dev, HPI_ADDR, addr);
> +	for (i = 0; i < count; i++)
> +		*data++ = le16_to_cpu(hpi_read_reg(dev, HPI_DATA));
> +
> +	spin_unlock_irqrestore(&dev->hpi.lock, flags);
> +}
> +
> +static inline void hpi_set_bits(struct c67x00_device *dev, u16 reg, u16 mask)
> +{
> +	u16 value;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&dev->hpi.lock, flags);
> +	value = hpi_read_word_nolock(dev, reg);
> +	hpi_write_word_nolock(dev, reg, value | mask);
> +	spin_unlock_irqrestore(&dev->hpi.lock, flags);
> +}
> +
> +static inline void hpi_clear_bits(struct c67x00_device *dev, u16 reg, u16 mask)
> +{
> +	u16 value;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&dev->hpi.lock, flags);
> +	value = hpi_read_word_nolock(dev, reg);
> +	hpi_write_word_nolock(dev, reg, value & ~mask);
> +	spin_unlock_irqrestore(&dev->hpi.lock, flags);
> +}
> +
> +static inline u16 hpi_recv_mbox(struct c67x00_device *dev)
> +{
> +	u16 value;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&dev->hpi.lock, flags);
> +	value = hpi_read_reg(dev, HPI_MAILBOX);
> +	spin_unlock_irqrestore(&dev->hpi.lock, flags);
> +
> +	return value;
> +}
> +
> +static inline u16 hpi_send_mbox(struct c67x00_device *dev, u16 value)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&dev->hpi.lock, flags);
> +	hpi_write_reg(dev, HPI_MAILBOX, value);
> +	spin_unlock_irqrestore(&dev->hpi.lock, flags);
> +
> +	return value;
> +}

Strike the "inline" from all the above, and let the compiler decide
if the space savings are worthwhile.  (I'd guess:  mostly not.)
Given icache, time savings are likely negligible.

^ permalink raw reply

* [PATCH] [POWERPC] Fix incorrectly tagged __devinitdata structures
From: Grant Likely @ 2008-02-01 21:51 UTC (permalink / raw)
  To: jwboyer, paulus, linuxppc-dev, jacmet

From: Grant Likely <grant.likely@secretlab.ca>

Fix compile errors in the xilinxfb, xsysace and uartlite drivers used
by the Xilinx Virtex platform

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

Paul, Josh: this fixes a compile error in mainline.

 drivers/block/xsysace.c   |    2 +-
 drivers/serial/uartlite.c |    2 +-
 drivers/video/xilinxfb.c  |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index 78ebfff..1110e1b 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -1202,7 +1202,7 @@ static int __devexit ace_of_remove(struct of_device *op)
 }
 
 /* Match table for of_platform binding */
-static struct of_device_id __devinit ace_of_match[] = {
+static struct of_device_id ace_of_match[] __devinitdata = {
 	{ .compatible = "xilinx,xsysace", },
 	{},
 };
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index 8094340..c54a5ad 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -618,7 +618,7 @@ static int __devexit ulite_of_remove(struct of_device *op)
 }
 
 /* Match table for of_platform binding */
-static struct of_device_id __devinit ulite_of_match[] = {
+static struct of_device_id ulite_of_match[] __devinitdata = {
 	{ .type = "serial", .compatible = "xilinx,uartlite", },
 	{},
 };
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index e38d3b7..c92e99e 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -459,7 +459,7 @@ static int __devexit xilinxfb_of_remove(struct of_device *op)
 }
 
 /* Match table for of_platform binding */
-static struct of_device_id __devinit xilinxfb_of_match[] = {
+static struct of_device_id xilinxfb_of_match[] __devinitdata = {
 	{ .compatible = "xilinx,ml300-fb", },
 	{},
 };

^ permalink raw reply related

* RE: 83xx immap_qe.h -> SIR type def error?
From: Russell McGuire @ 2008-02-01 21:37 UTC (permalink / raw)
  To: 'Kumar Gala'; +Cc: linuxppc-embedded
In-Reply-To: <1ADE91E0-282D-4455-9754-886846B3EB90@kernel.crashing.org>

I should state, I am looking at the MPC8360ERM.pdf Rev 2.0

-Russ

> -----Original Message-----
> From: Russell McGuire [mailto:rmcguire@videopresence.com]
> Sent: Friday, February 01, 2008 1:03 PM
> To: 'Kumar Gala'
> Cc: 'linuxppc-embedded@ozlabs.org'
> Subject: RE: 83xx immap_qe.h -> SIR type def error?
> 
> Kumar,
> 
> Yes in the main memeory map they are just listed as 1K RAM blocks.
> However, in the UM Section 36.6.1 <pg 36-12 or pg 1728 in the PDF>.
> 
> It gives the breakout for the RAM, which clearly indicates 16 bit fields.
> <Here is a short clip from Figure 36-8>
> 
> Access: Read/Write
> 0 1 2 3 4 5 6 7 10 11 13 14 15
> MCC SWTR SSEL 1 SSEL 2 SSEL 3 SSEL 4 SGS CSEL CNT BYT LST
> Figure 36-8. SI RAM Entry for UCC
> 
> Honest, mistake as if I were writing the header file I'd not have time to
> ready all 2000+ pages of the UM. We find these only as somebody goes in an
> tries to use them.
> And I am guessing not a lot of customers use the SI block.
> 
> -Russ
> > -----Original Message-----
> > From: Kumar Gala [mailto:galak@kernel.crashing.org]
> > Sent: Friday, February 01, 2008 6:56 AM
> > To: rmcguire@videopresence.com
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: 83xx immap_qe.h -> SIR type def error?
> >
> >
> > On Feb 1, 2008, at 5:47 AM, Russell McGuire wrote:
> >
> > > All Freescale,
> > >
> > > Not sure if this is the place to post this, but I have run across
> > > what I
> > > consider to be a possible type error in the immap_qe.h file, for the
> > > asm/powerpc branch.
> > >
> > > In the file immap_qe.h
> > >
> > > /* SI Routing Tables */
> > > struct sir {
> > > 	u8  tx[0x400];
> > > 	u8  rx[0x400];
> > > 	u8  res0[0x800];
> > > }
> > >
> > > Shouldn't these types be defined as __be16 ?
> > >
> > > According to the Freescale manual this is a 16 bit field, not an 8-bit
> > > field.
> > >
> > > Spent an hour trying to figure out why I couldn't fill this field
> > > out with
> > > upper 8 bits last night.
> > >
> > > Thoughts?
> >
> > I'm guessing it was done this way since they are just looked as base
> > offsets.  Where in the UM do you see anything about them being 16-bit
> > quantities?  (I'm really know little about this).
> >
> > - k

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox