[0/16] Preliminary Ebony (440GP) support for arch/powerpc

[0/16] Preliminary Ebony (440GP) support for arch/powerpc

[David Gibson]

Here is a preliminary set of patches implementing support for the
440GP based Ebony evaluation board in arch/powerpc.  A number of the
earlier patches are in Paul's queue already, so may appear in
powerpc.git at any point.  Most of the later ones need at least some
cleanup or reworking before they'll be ready for merging.

With these patches I can boot to a shell prompt on initrd on my Ebony
board.  There are still a bunch of problems: clock timings are way out
(runs about 4* fast), things freeze up when I attempt to use an
nfsroot, many devices aren't supported.  A lot of things are hardcoded
in the device tree, so you may well have to tweak it if your Ebony is
different from mine.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[PATCH 3/16] [powerpc] Use udbg_early_init() on ppc32

[David Gibson]

udbg_early_init() is a function used on 64 bit systems, which
initializes whichever early udbg backend is configured.  This function
is not called on 32-bit, however if btext early debug is enabled it
does have an explicit, inline, #ifdef-ed assignment performing
analagous initialization.

This patch makes things more uniform by folding the btext
initialization as an option into udbg_early_init() and calling that
from the 32-bit setup path.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/kernel/btext.c    |    9 +++++++++
 arch/powerpc/kernel/setup_32.c |    8 ++------
 arch/powerpc/kernel/udbg.c     |    2 ++
 include/asm-powerpc/udbg.h     |    1 +
 4 files changed, 14 insertions(+), 6 deletions(-)

Index: working-2.6/arch/powerpc/kernel/btext.c
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/btext.c	2007-01-24 12:01:17.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/btext.c	2007-02-13 15:53:18.000000000 +1100
@@ -18,6 +18,7 @@
 #include <asm/io.h>
 #include <asm/lmb.h>
 #include <asm/processor.h>
+#include <asm/udbg.h>
 
 #define NO_SCROLL
 
@@ -912,3 +913,11 @@ static unsigned char vga_font[cmapsz] = 
 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 0x00, 0x00, 0x00, 0x00,
 };
+
+void __init udbg_init_btext(void)
+{
+	/* If btext is enabled, we might have a BAT setup for early display,
+	 * thus we do enable some very basic udbg output
+	 */
+	udbg_putc = btext_drawchar;
+}
Index: working-2.6/arch/powerpc/kernel/setup_32.c
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/setup_32.c	2007-02-09 09:57:55.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/setup_32.c	2007-02-13 15:50:54.000000000 +1100
@@ -116,12 +116,8 @@ unsigned long __init early_init(unsigned
  */
 void __init machine_init(unsigned long dt_ptr, unsigned long phys)
 {
-	/* If btext is enabled, we might have a BAT setup for early display,
-	 * thus we do enable some very basic udbg output
-	 */
-#ifdef CONFIG_BOOTX_TEXT
-	udbg_putc = btext_drawchar;
-#endif
+	/* Enable early debugging if any specified (see udbg.h) */
+	udbg_early_init();
 
 	/* Do some early initialization based on the flat device tree */
 	early_init_devtree(__va(dt_ptr));
Index: working-2.6/arch/powerpc/kernel/udbg.c
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/udbg.c	2007-02-09 09:57:55.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/udbg.c	2007-02-13 15:50:54.000000000 +1100
@@ -49,6 +49,8 @@ void __init udbg_early_init(void)
 	udbg_init_debug_beat();
 #elif defined(CONFIG_PPC_EARLY_DEBUG_PAS_REALMODE)
 	udbg_init_pas_realmode();
+#elif defined(CONFIG_BOOTX_TEXT)
+	udbg_init_btext();
 #endif
 }
 
Index: working-2.6/include/asm-powerpc/udbg.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/udbg.h	2007-02-09 09:57:55.000000000 +1100
+++ working-2.6/include/asm-powerpc/udbg.h	2007-02-13 15:50:54.000000000 +1100
@@ -46,6 +46,7 @@ extern void __init udbg_init_iseries(voi
 extern void __init udbg_init_rtas_panel(void);
 extern void __init udbg_init_rtas_console(void);
 extern void __init udbg_init_debug_beat(void);
+extern void __init udbg_init_btext(void);
 
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_UDBG_H */

Re: [PATCH 3/16] [powerpc] Use udbg_early_init() on ppc32

[Benjamin Herrenschmidt]

On Tue, 2007-02-13 at 17:10 +1100, David Gibson wrote:
> udbg_early_init() is a function used on 64 bit systems, which
> initializes whichever early udbg backend is configured.  This function
> is not called on 32-bit, however if btext early debug is enabled it
> does have an explicit, inline, #ifdef-ed assignment performing
> analagous initialization.
> 
> This patch makes things more uniform by folding the btext
> initialization as an option into udbg_early_init() and calling that
> from the 32-bit setup path.
> 
> Signed-off-by: David Gibson <dwg@au1.ibm.com>

Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

[PATCH 6/16] Port 44x MMU definitions to ARCH=powerpc

[David Gibson]

This patch moves the mmu.h definitions which are still relevant for
ARCH=powerpc from include/asm-ppc/mmu.h to their own file,
include/asm-powerpc/mmu_44x.h.  The new file is included from
asm-powerpc/mmu.h, and a couple of other tweaks to correct mmu
definitions for 44x are made.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/kernel/head_44x.S |    4 +-
 arch/powerpc/mm/44x_mmu.c      |   81 ++++++++---------------------------------
 arch/powerpc/mm/mmu_decl.h     |    2 +
 include/asm-powerpc/mmu.h      |    4 +-
 include/asm-powerpc/mmu_44x.h  |   74 +++++++++++++++++++++++++++++++++++++
 5 files changed, 98 insertions(+), 67 deletions(-)

Index: working-2.6/include/asm-powerpc/mmu.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/mmu.h	2007-01-24 12:01:20.000000000 +1100
+++ working-2.6/include/asm-powerpc/mmu.h	2007-02-05 14:24:52.000000000 +1100
@@ -2,7 +2,9 @@
 #define _ASM_POWERPC_MMU_H_
 #ifdef __KERNEL__
 
-#ifndef CONFIG_PPC64
+#ifdef CONFIG_44x
+#include <asm/mmu_44x.h>
+#elif !defined(CONFIG_PPC64)
 #include <asm-ppc/mmu.h>
 #else
 
Index: working-2.6/include/asm-powerpc/mmu_44x.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ working-2.6/include/asm-powerpc/mmu_44x.h	2007-02-05 15:25:11.000000000 +1100
@@ -0,0 +1,74 @@
+#ifndef _ASM_POWERPC_MMU_44X_H_
+#define _ASM_POWERPC_MMU_44X_H_
+
+#ifndef __ASSEMBLY__
+
+typedef unsigned long long phys_addr_t;
+extern phys_addr_t fixup_bigphys_addr(phys_addr_t, phys_addr_t);
+#define PHYS_FMT	"%16Lx"
+
+typedef struct {
+	unsigned long id;
+	unsigned long vdso_base;
+} mm_context_t;
+
+#endif /* !__ASSEMBLY__ */
+
+/*
+ * PPC440 support
+ */
+#define PPC44x_MMUCR_TID	0x000000ff
+#define PPC44x_MMUCR_STS	0x00010000
+
+#define	PPC44x_TLB_PAGEID	0
+#define	PPC44x_TLB_XLAT		1
+#define	PPC44x_TLB_ATTRIB	2
+
+/* Page identification fields */
+#define PPC44x_TLB_EPN_MASK	0xfffffc00      /* Effective Page Number */
+#define	PPC44x_TLB_VALID	0x00000200      /* Valid flag */
+#define PPC44x_TLB_TS		0x00000100	/* Translation address space */
+#define PPC44x_TLB_1K		0x00000000	/* Page sizes */
+#define PPC44x_TLB_4K		0x00000010
+#define PPC44x_TLB_16K		0x00000020
+#define PPC44x_TLB_64K		0x00000030
+#define PPC44x_TLB_256K		0x00000040
+#define PPC44x_TLB_1M		0x00000050
+#define PPC44x_TLB_16M		0x00000070
+#define	PPC44x_TLB_256M		0x00000090
+
+/* Translation fields */
+#define PPC44x_TLB_RPN_MASK	0xfffffc00      /* Real Page Number */
+#define	PPC44x_TLB_ERPN_MASK	0x0000000f
+
+/* Storage attribute and access control fields */
+#define PPC44x_TLB_ATTR_MASK	0x0000ff80
+#define PPC44x_TLB_U0		0x00008000      /* User 0 */
+#define PPC44x_TLB_U1		0x00004000      /* User 1 */
+#define PPC44x_TLB_U2		0x00002000      /* User 2 */
+#define PPC44x_TLB_U3		0x00001000      /* User 3 */
+#define PPC44x_TLB_W		0x00000800      /* Caching is write-through */
+#define PPC44x_TLB_I		0x00000400      /* Caching is inhibited */
+#define PPC44x_TLB_M		0x00000200      /* Memory is coherent */
+#define PPC44x_TLB_G		0x00000100      /* Memory is guarded */
+#define PPC44x_TLB_E		0x00000080      /* Memory is guarded */
+
+#define PPC44x_TLB_PERM_MASK	0x0000003f
+#define PPC44x_TLB_UX		0x00000020      /* User execution */
+#define PPC44x_TLB_UW		0x00000010      /* User write */
+#define PPC44x_TLB_UR		0x00000008      /* User read */
+#define PPC44x_TLB_SX		0x00000004      /* Super execution */
+#define PPC44x_TLB_SW		0x00000002      /* Super write */
+#define PPC44x_TLB_SR		0x00000001      /* Super read */
+
+/* Number of TLB entries */
+#define PPC44x_TLB_SIZE		64
+
+/* TLB entry offset/size used for pinning kernel lowmem */
+#define PPC44x_PIN_SHIFT	28
+#define PPC_PIN_SIZE		(1 << PPC44x_PIN_SHIFT)
+
+#define PPC44x_EARLY_TLBS	1
+
+#endif /* _ASM_POWERPC_MMU_44X_H_ */
+
Index: working-2.6/arch/powerpc/mm/44x_mmu.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/44x_mmu.c	2006-12-08 10:42:48.000000000 +1100
+++ working-2.6/arch/powerpc/mm/44x_mmu.c	2007-02-05 15:25:19.000000000 +1100
@@ -24,73 +24,35 @@
  *
  */
 
-#include <linux/signal.h>
-#include <linux/sched.h>
-#include <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/string.h>
-#include <linux/types.h>
-#include <linux/ptrace.h>
-#include <linux/mman.h>
-#include <linux/mm.h>
-#include <linux/swap.h>
-#include <linux/stddef.h>
-#include <linux/vmalloc.h>
-#include <linux/init.h>
-#include <linux/delay.h>
-#include <linux/highmem.h>
-
-#include <asm/pgalloc.h>
-#include <asm/prom.h>
-#include <asm/io.h>
-#include <asm/mmu_context.h>
-#include <asm/pgtable.h>
 #include <asm/mmu.h>
-#include <asm/uaccess.h>
-#include <asm/smp.h>
-#include <asm/bootx.h>
-#include <asm/machdep.h>
-#include <asm/setup.h>
 
 #include "mmu_decl.h"
 
-extern char etext[], _stext[];
-
 /* Used by the 44x TLB replacement exception handler.
  * Just needed it declared someplace.
  */
-unsigned int tlb_44x_index = 0;
-unsigned int tlb_44x_hwater = 62;
+unsigned int tlb_44x_index; /* = 0 */
+unsigned int tlb_44x_hwater = PPC44x_TLB_SIZE - 1 - PPC44x_EARLY_TLBS;
 
 /*
  * "Pins" a 256MB TLB entry in AS0 for kernel lowmem
  */
-static void __init
-ppc44x_pin_tlb(int slot, unsigned int virt, unsigned int phys)
+static void __init ppc44x_pin_tlb(unsigned int virt, unsigned int phys)
 {
-	unsigned long attrib = 0;
-
-	__asm__ __volatile__("\
-	clrrwi	%2,%2,10\n\
-	ori	%2,%2,%4\n\
-	clrrwi	%1,%1,10\n\
-	li	%0,0\n\
-	ori	%0,%0,%5\n\
-	tlbwe	%2,%3,%6\n\
-	tlbwe	%1,%3,%7\n\
-	tlbwe	%0,%3,%8"
+	__asm__ __volatile__(
+		"tlbwe	%2,%3,%4\n"
+		"tlbwe	%1,%3,%5\n"
+		"tlbwe	%0,%3,%6\n"
 	:
-	: "r" (attrib), "r" (phys), "r" (virt), "r" (slot),
-	  "i" (PPC44x_TLB_VALID | PPC44x_TLB_256M),
-	  "i" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
+	: "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
+	  "r" (phys),
+	  "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M),
+	  "r" (tlb_44x_hwater--), /* slot for this TLB entry */
 	  "i" (PPC44x_TLB_PAGEID),
 	  "i" (PPC44x_TLB_XLAT),
 	  "i" (PPC44x_TLB_ATTRIB));
 }
 
-/*
- * MMU_init_hw does the chip-specific initialization of the MMU hardware.
- */
 void __init MMU_init_hw(void)
 {
 	flush_instruction_cache();
@@ -98,22 +60,13 @@ void __init MMU_init_hw(void)
 
 unsigned long __init mmu_mapin_ram(void)
 {
-	unsigned int pinned_tlbs = 1;
-	int i;
+	unsigned long addr;
 
-	/* Determine number of entries necessary to cover lowmem */
-	pinned_tlbs = (unsigned int)
-		(_ALIGN(total_lowmem, PPC_PIN_SIZE) >> PPC44x_PIN_SHIFT);
-
-	/* Write upper watermark to save location */
-	tlb_44x_hwater = PPC44x_LOW_SLOT - pinned_tlbs;
-
-	/* If necessary, set additional pinned TLBs */
-	if (pinned_tlbs > 1)
-		for (i = (PPC44x_LOW_SLOT-(pinned_tlbs-1)); i < PPC44x_LOW_SLOT; i++) {
-			unsigned int phys_addr = (PPC44x_LOW_SLOT-i) * PPC_PIN_SIZE;
-			ppc44x_pin_tlb(i, phys_addr+PAGE_OFFSET, phys_addr);
-		}
+	/* Pin in enough TLBs to cover any lowmem not covered by the
+	 * initial 256M mapping established in head_44x.S */
+	for (addr = PPC_PIN_SIZE; addr < total_lowmem;
+	     addr += PPC_PIN_SIZE)
+		ppc44x_pin_tlb(addr + PAGE_OFFSET, addr);
 
 	return total_lowmem;
 }
Index: working-2.6/arch/powerpc/mm/mmu_decl.h
===================================================================
--- working-2.6.orig/arch/powerpc/mm/mmu_decl.h	2006-12-08 10:42:48.000000000 +1100
+++ working-2.6/arch/powerpc/mm/mmu_decl.h	2007-02-05 14:24:52.000000000 +1100
@@ -35,8 +35,10 @@ extern int __map_without_bats;
 extern unsigned long ioremap_base;
 extern unsigned int rtas_data, rtas_size;
 
+#ifdef CONFIG_CLASSIC32
 extern PTE *Hash, *Hash_end;
 extern unsigned long Hash_size, Hash_mask;
+#endif /* CONFIG_CLASSIC32 */
 
 extern unsigned int num_tlbcam_entries;
 #endif
Index: working-2.6/arch/powerpc/kernel/head_44x.S
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/head_44x.S	2007-02-05 14:24:52.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/head_44x.S	2007-02-05 15:25:11.000000000 +1100
@@ -120,8 +120,8 @@ skpinv:	addi	r4,r4,1				/* Increment */
  * Configure and load pinned entry into TLB slot 63.
  */
 
-	lis	r3,KERNELBASE@h		/* Load the kernel virtual address */
-	ori	r3,r3,KERNELBASE@l
+	lis	r3,PAGE_OFFSET@h
+	ori	r3,r3,PAGE_OFFSET@l
 
 	/* Kernel is at the base of RAM */
 	li r4, 0			/* Load the kernel physical address */

Re: [PATCH 6/16] Port 44x MMU definitions to ARCH=powerpc

[Benjamin Herrenschmidt]

> +typedef unsigned long long phys_addr_t;
> +extern phys_addr_t fixup_bigphys_addr(phys_addr_t, phys_addr_t);
> +#define PHYS_FMT	"%16Lx"

Do we still need that fixup code ? Since we now have full 64 bits
capable ioremap, we don't need to play tricks anymore. I'd rather get
rid of them completely.

Ben.

Re: [PATCH 6/16] Port 44x MMU definitions to ARCH=powerpc

[Roland Dreier]

 > > +typedef unsigned long long phys_addr_t;
 > > +extern phys_addr_t fixup_bigphys_addr(phys_addr_t, phys_addr_t);
 > > +#define PHYS_FMT	"%16Lx"
 > 
 > Do we still need that fixup code ? Since we now have full 64 bits
 > capable ioremap, we don't need to play tricks anymore. I'd rather get
 > rid of them completely.

Maybe make the fixup code print a warning when it actually changes an
address below 4G so we can track down all the places relying on this?

 - R.

Re: [PATCH 6/16] Port 44x MMU definitions to ARCH=powerpc

[Josh Boyer]

On Tue, 2007-02-13 at 09:13 -0800, Roland Dreier wrote:
>  > > +typedef unsigned long long phys_addr_t;
>  > > +extern phys_addr_t fixup_bigphys_addr(phys_addr_t, phys_addr_t);
>  > > +#define PHYS_FMT	"%16Lx"
>  > 
>  > Do we still need that fixup code ? Since we now have full 64 bits
>  > capable ioremap, we don't need to play tricks anymore. I'd rather get
>  > rid of them completely.
> 
> Maybe make the fixup code print a warning when it actually changes an
> address below 4G so we can track down all the places relying on this?

That sounds like a good idea.  As boards get ported over, the authors
will hopefully fix them up.

josh

Re: [PATCH 6/16] Port 44x MMU definitions to ARCH=powerpc

[Benjamin Herrenschmidt]

On Tue, 2007-02-13 at 09:13 -0800, Roland Dreier wrote:
>  > > +typedef unsigned long long phys_addr_t;
>  > > +extern phys_addr_t fixup_bigphys_addr(phys_addr_t, phys_addr_t);
>  > > +#define PHYS_FMT	"%16Lx"
>  > 
>  > Do we still need that fixup code ? Since we now have full 64 bits
>  > capable ioremap, we don't need to play tricks anymore. I'd rather get
>  > rid of them completely.
> 
> Maybe make the fixup code print a warning when it actually changes an
> address below 4G so we can track down all the places relying on this?

Good idea.

Ben.

[PATCH 5/16] powerpc: Add zImage platform hook for kernel address

[David Gibson]

Unlike "classic" 32 and 64-bit PowerPC processors, the early setup
code for 4xx is not able to relocate the kernel if loaded at an
address other than 0.  For 440 it's even potentially difficult to add
this support, because at entry the kernel doesn't necessarily know the
full MMU configuration.

This patch, therefore, adds a hook to the zImage wrapper code which
allows a platform to specify a function giving the address to which
the vmlinux must be moved before entering the kernel.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/boot/main.c |   19 +++++++++++++++----
 arch/powerpc/boot/ops.h  |    1 +
 2 files changed, 16 insertions(+), 4 deletions(-)

Index: working-2.6/arch/powerpc/boot/main.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/main.c	2007-01-12 14:43:34.000000000 +1100
+++ working-2.6/arch/powerpc/boot/main.c	2007-01-12 14:48:10.000000000 +1100
@@ -249,12 +249,23 @@ static void prep_kernel(unsigned long a1
 			vmlinuz.size);
 	}
 
-	/* Skip over the ELF header */
+	/* Move into final position */
+	if (platform_ops.vmlinux_addr) {
+		unsigned long old_addr = vmlinux.addr;
+		vmlinux.addr = platform_ops.vmlinux_addr(vmlinux.size);
 #ifdef DEBUG
-	printf("... skipping 0x%lx bytes of ELF header\n\r",
-			elfoffset);
+		printf("...moving kernel to final address 0x%lx\n\r", vmlinux.addr);
 #endif
-	vmlinux.addr += elfoffset;
+		memmove((void *)vmlinux.addr, (void *)old_addr+elfoffset,
+			vmlinux.size);
+	} else {
+		/* Just Skip over the ELF header */
+#ifdef DEBUG
+		printf("... skipping 0x%lx bytes of ELF header\n\r",
+		       elfoffset);
+#endif
+		vmlinux.addr += elfoffset;
+	}
 
 	flush_cache((void *)vmlinux.addr, vmlinux.size);
 }
Index: working-2.6/arch/powerpc/boot/ops.h
===================================================================
--- working-2.6.orig/arch/powerpc/boot/ops.h	2007-01-12 14:42:11.000000000 +1100
+++ working-2.6/arch/powerpc/boot/ops.h	2007-01-12 14:45:43.000000000 +1100
@@ -25,6 +25,7 @@ struct platform_ops {
 	void	(*free)(void *ptr);
 	void *	(*realloc)(void *ptr, unsigned long size);
 	void	(*exit)(void);
+	unsigned long (*vmlinux_addr)(unsigned long size);
 };
 extern struct platform_ops platform_ops;
 

[PATCH 4/16] powerpc: Allow duplicate lmb_reserve() calls

[David Gibson]

At present calling lmb_reserve() (and hence lmb_add_region()) twice
for exactly the same memory region will cause strange behaviour.

This makes life difficult when booting from a flat device tree with
memory reserve map.  Which regions are automatically reserved by the
kernel has changed over time, so it's quite possible a newer kernel
could attempt to auto-reserve a region which is also explicitly listed
in the device tree's reserve map, leading to trouble.

This patch avoids the problem by making lmb_reserve() ignore a call to
reserve a previously reserved region.  It also removes a now redundant
test designed to avoid one specific case of the problem noted above.

At present, this patch deals only with duplicate reservations of an
identical region.  Attempting to reserve two different, but
overlapping regions will still cause problems.  I might post another
patch later dealing with this case, but I'm avoiding it now since it
is substantially more complicated to deal with, less likely to occur
and more likely to indicate a genuine bug elsewhere if it does occur.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---


 arch/powerpc/kernel/prom.c |    3 ---
 arch/powerpc/mm/lmb.c      |    4 ++++
 2 files changed, 4 insertions(+), 3 deletions(-)

Index: working-2.6/arch/powerpc/mm/lmb.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/lmb.c	2007-02-06 16:21:02.000000000 +1100
+++ working-2.6/arch/powerpc/mm/lmb.c	2007-02-06 16:22:32.000000000 +1100
@@ -146,6 +146,10 @@ static long __init lmb_add_region(struct
 		unsigned long rgnbase = rgn->region[i].base;
 		unsigned long rgnsize = rgn->region[i].size;
 
+		if ((rgnbase == base) && (rgnsize == size))
+			/* Already have this region, so we're done */
+			return 0;
+
 		adjacent = lmb_addrs_adjacent(base,size,rgnbase,rgnsize);
 		if ( adjacent > 0 ) {
 			rgn->region[i].base -= size;
Index: working-2.6/arch/powerpc/kernel/prom.c
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/prom.c	2007-02-06 16:22:48.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/prom.c	2007-02-06 16:22:57.000000000 +1100
@@ -954,9 +954,6 @@ static void __init early_reserve_mem(voi
 		size = *(reserve_map++);
 		if (size == 0)
 			break;
-		/* skip if the reservation is for the blob */
-		if (base == self_base && size == self_size)
-			continue;
 		DBG("reserving: %llx -> %llx\n", base, size);
 		lmb_reserve(base, size);
 	}

Re: [PATCH 4/16] powerpc: Allow duplicate lmb_reserve() calls

[Michael Neuling]

> At present calling lmb_reserve() (and hence lmb_add_region()) twice
> for exactly the same memory region will cause strange behaviour.
> 
> This makes life difficult when booting from a flat device tree with
> memory reserve map.  Which regions are automatically reserved by the
> kernel has changed over time, so it's quite possible a newer kernel
> could attempt to auto-reserve a region which is also explicitly listed
> in the device tree's reserve map, leading to trouble.
> 
> This patch avoids the problem by making lmb_reserve() ignore a call to
> reserve a previously reserved region.  It also removes a now redundant
> test designed to avoid one specific case of the problem noted above.
> 
> At present, this patch deals only with duplicate reservations of an
> identical region.  Attempting to reserve two different, but
> overlapping regions will still cause problems.  I might post another
> patch later dealing with this case, but I'm avoiding it now since it
> is substantially more complicated to deal with, less likely to occur
> and more likely to indicate a genuine bug elsewhere if it does occur.
> 
> Signed-off-by: David Gibson <dwg@au1.ibm.com>
> ---
> 
> 
>  arch/powerpc/kernel/prom.c |    3 ---
>  arch/powerpc/mm/lmb.c      |    4 ++++
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> Index: working-2.6/arch/powerpc/mm/lmb.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/mm/lmb.c	2007-02-06 16:21:02.000000000 +
1100
> +++ working-2.6/arch/powerpc/mm/lmb.c	2007-02-06 16:22:32.000000000 +1100
> @@ -146,6 +146,10 @@ static long __init lmb_add_region(struct
>  		unsigned long rgnbase = rgn->region[i].base;
>  		unsigned long rgnsize = rgn->region[i].size;
>  
> +		if ((rgnbase == base) && (rgnsize == size))
> +			/* Already have this region, so we're done */
> +			return 0;

This might indicate that two things actually want to use the same memory
region.  How about we print a warning?

Mikey

Re: [PATCH 4/16] powerpc: Allow duplicate lmb_reserve() calls

[Michael Ellerman]

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

On Tue, 2007-02-13 at 18:05 +1100, Michael Neuling wrote:
> > At present calling lmb_reserve() (and hence lmb_add_region()) twice
> > for exactly the same memory region will cause strange behaviour.
> > 
> > This makes life difficult when booting from a flat device tree with
> > memory reserve map.  Which regions are automatically reserved by the
> > kernel has changed over time, so it's quite possible a newer kernel
> > could attempt to auto-reserve a region which is also explicitly listed
> > in the device tree's reserve map, leading to trouble.
> > 
> > This patch avoids the problem by making lmb_reserve() ignore a call to
> > reserve a previously reserved region.  It also removes a now redundant
> > test designed to avoid one specific case of the problem noted above.
> > 
> > At present, this patch deals only with duplicate reservations of an
> > identical region.  Attempting to reserve two different, but
> > overlapping regions will still cause problems.  I might post another
> > patch later dealing with this case, but I'm avoiding it now since it
> > is substantially more complicated to deal with, less likely to occur
> > and more likely to indicate a genuine bug elsewhere if it does occur.
> > 
> > Signed-off-by: David Gibson <dwg@au1.ibm.com>
> > ---
> > 
> > 
> >  arch/powerpc/kernel/prom.c |    3 ---
> >  arch/powerpc/mm/lmb.c      |    4 ++++
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > Index: working-2.6/arch/powerpc/mm/lmb.c
> > ===================================================================
> > --- working-2.6.orig/arch/powerpc/mm/lmb.c	2007-02-06 16:21:02.000000000 +
> 1100
> > +++ working-2.6/arch/powerpc/mm/lmb.c	2007-02-06 16:22:32.000000000 +1100
> > @@ -146,6 +146,10 @@ static long __init lmb_add_region(struct
> >  		unsigned long rgnbase = rgn->region[i].base;
> >  		unsigned long rgnsize = rgn->region[i].size;
> >  
> > +		if ((rgnbase == base) && (rgnsize == size))
> > +			/* Already have this region, so we're done */
> > +			return 0;
> 
> This might indicate that two things actually want to use the same memory
> region.  How about we print a warning?

It'd be nice, but it'll spit out lots of spurious warnings for exactly
the reason David describes - things that used to be in the reserve map
are now auto reserved.

What we probably should warn for is overlapping, but not duplicated
regions - I can't think if any reason that _doesn't_ indicate a bug.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 4/16] powerpc: Allow duplicate lmb_reserve() calls

[Benjamin Herrenschmidt]

> This might indicate that two things actually want to use the same memory
> region.  How about we print a warning?

I don't think so. If we want to print that sort of warning, I'd rather
do it in the code that creates the reserve map (not in the kernel) or if
the reserve map has overlapping but not identical entries.

There are various cases where we used to rely on things being in the
reserve map and that the kernel "knows" how to reserve itself (like the
initrd typically) where warnings would just be confusing.

Ben.

[PATCH 8/16] Define FIXED_PORT flag for serial_core

[David Gibson]

At present, the serial core always allows setserial in userspace to
change the port address, irq and base clock of any serial port.  That
makes sense for legacy ISA ports, but not for (say) embedded ns16550
compatible serial ports at peculiar addresses.  In these cases, the
kernel code configuring the ports must know exactly where they are,
and their clocking arrangements (which can be unusual on embedded
boards).  It doesn't make sense for userspace to change these
settings.

Therefore, this patch defines a UPF_FIXED_PORT flag for the uart_port
structure.  If this flag is set when the serial port is configured,
any attempts to alter the port's type, io address, irq or base clock
with setserial are ignored.

In addition this patch uses the new flag when initializing serial
ports for system-on-chip devices in
arch/powerpc/kernel/legacy_serial.c

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/kernel/legacy_serial.c |    3 ++-
 drivers/serial/serial_core.c        |   22 +++++++++++++---------
 include/linux/serial_core.h         |    1 +
 3 files changed, 16 insertions(+), 10 deletions(-)

Index: working-2.6/drivers/serial/serial_core.c
===================================================================
--- working-2.6.orig/drivers/serial/serial_core.c	2007-01-24 12:01:19.000000000 +1100
+++ working-2.6/drivers/serial/serial_core.c	2007-02-13 12:37:43.000000000 +1100
@@ -672,19 +672,21 @@ static int uart_set_info(struct uart_sta
 	 */
 	mutex_lock(&state->mutex);
 
-	change_irq  = new_serial.irq != port->irq;
+	change_irq  = !(port->flags & UPF_FIXED_PORT)
+		&& new_serial.irq != port->irq;
 
 	/*
 	 * Since changing the 'type' of the port changes its resource
 	 * allocations, we should treat type changes the same as
 	 * IO port changes.
 	 */
-	change_port = new_port != port->iobase ||
-		      (unsigned long)new_serial.iomem_base != port->mapbase ||
-		      new_serial.hub6 != port->hub6 ||
-		      new_serial.io_type != port->iotype ||
-		      new_serial.iomem_reg_shift != port->regshift ||
-		      new_serial.type != port->type;
+	change_port = !(port->flags & UPF_FIXED_PORT)
+		&& (new_port != port->iobase ||
+		    (unsigned long)new_serial.iomem_base != port->mapbase ||
+		    new_serial.hub6 != port->hub6 ||
+		    new_serial.io_type != port->iotype ||
+		    new_serial.iomem_reg_shift != port->regshift ||
+		    new_serial.type != port->type);
 
 	old_flags = port->flags;
 	new_flags = new_serial.flags;
@@ -796,8 +798,10 @@ static int uart_set_info(struct uart_sta
 		}
 	}
 
-	port->irq              = new_serial.irq;
-	port->uartclk          = new_serial.baud_base * 16;
+	if (change_irq)
+		port->irq      = new_serial.irq;
+	if (! (port->flags & UPF_FIXED_PORT))
+		port->uartclk  = new_serial.baud_base * 16;
 	port->flags            = (port->flags & ~UPF_CHANGE_MASK) |
 				 (new_flags & UPF_CHANGE_MASK);
 	port->custom_divisor   = new_serial.custom_divisor;
Index: working-2.6/include/linux/serial_core.h
===================================================================
--- working-2.6.orig/include/linux/serial_core.h	2007-01-24 12:01:21.000000000 +1100
+++ working-2.6/include/linux/serial_core.h	2007-02-13 12:37:43.000000000 +1100
@@ -260,6 +260,7 @@ struct uart_port {
 #define UPF_CONS_FLOW		((__force upf_t) (1 << 23))
 #define UPF_SHARE_IRQ		((__force upf_t) (1 << 24))
 #define UPF_BOOT_AUTOCONF	((__force upf_t) (1 << 28))
+#define UPF_FIXED_PORT		((__force upf_t) (1 << 29))
 #define UPF_DEAD		((__force upf_t) (1 << 30))
 #define UPF_IOREMAP		((__force upf_t) (1 << 31))
 
Index: working-2.6/arch/powerpc/kernel/legacy_serial.c
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/legacy_serial.c	2007-02-13 12:37:53.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/legacy_serial.c	2007-02-13 12:38:03.000000000 +1100
@@ -115,7 +115,8 @@ static int __init add_legacy_soc_port(st
 {
 	u64 addr;
 	const u32 *addrp;
-	upf_t flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ;
+	upf_t flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ
+		| UPF_FIXED_PORT;
 	struct device_node *tsi = of_get_parent(np);
 
 	/* We only support ports that have a clock frequency properly

[PATCH 7/16] Early serial debug support for PPC44x

[David Gibson]

This patch adds support for early serial debugging via the built in
port on IBM/AMCC PowerPC 44x CPUs.  It uses a bolted TLB entry in
address space 1 for the UART's mapping, allowing robust debugging both
before and after the initialization of the MMU.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/Kconfig.debug       |   18 +++++++++++----
 arch/powerpc/kernel/Makefile     |    1 
 arch/powerpc/kernel/head_44x.S   |   34 +++++++++++-----------------
 arch/powerpc/kernel/misc_44x.S   |   46 +++++++++++++++++++++++++++++++++++++++
 arch/powerpc/kernel/udbg.c       |    3 ++
 arch/powerpc/kernel/udbg_16550.c |   24 ++++++++++++++++++++
 include/asm-powerpc/mmu_44x.h    |    6 +++++
 include/asm-powerpc/udbg.h       |    1 
 8 files changed, 107 insertions(+), 26 deletions(-)

Index: working-2.6/arch/powerpc/Kconfig.debug
===================================================================
--- working-2.6.orig/arch/powerpc/Kconfig.debug	2007-02-09 09:57:55.000000000 +1100
+++ working-2.6/arch/powerpc/Kconfig.debug	2007-02-09 11:51:03.000000000 +1100
@@ -130,11 +130,6 @@ config BOOTX_TEXT
 	  Say Y here to see progress messages from the boot firmware in text
 	  mode. Requires either BootX or Open Firmware.
 
-config SERIAL_TEXT_DEBUG
-	bool "Support for early boot texts over serial port"
-	depends on 4xx || LOPEC || MV64X60 || PPLUS || PRPMC800 || \
-		PPC_GEN550 || PPC_MPC52xx
-
 config PPC_EARLY_DEBUG
 	bool "Early debugging (dangerous)"
 
@@ -199,6 +194,19 @@ config PPC_EARLY_DEBUG_BEAT
 	help
 	  Select this to enable early debugging for Celleb with Beat.
 
+config PPC_EARLY_DEBUG_44x
+	bool "Early serial debugging for IBM 44x CPUs"
+	depends on 44x
+	select PPC_UDBG_16550
+	help
+	  Select this to enable early debugging for IBM 44x chips via the
+	  inbuilt serial port.
+
 endchoice
 
+config PPC_EARLY_DEBUG_44x_PHYSADDR
+	hex
+	depends PPC_EARLY_DEBUG_44x
+	default "0x140000200"
+
 endmenu
Index: working-2.6/arch/powerpc/kernel/head_44x.S
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/head_44x.S	2007-02-09 11:51:01.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/head_44x.S	2007-02-09 11:51:03.000000000 +1100
@@ -172,36 +172,28 @@ skpinv:	addi	r4,r4,1				/* Increment */
 	isync
 
 4:
-#ifdef CONFIG_SERIAL_TEXT_DEBUG
-	/*
-	 * Add temporary UART mapping for early debug.
-	 * We can map UART registers wherever we want as long as they don't
-	 * interfere with other system mappings (e.g. with pinned entries).
-	 * For an example of how we handle this - see ocotea.h.       --ebs
-	 */
+#ifdef CONFIG_PPC_EARLY_DEBUG_44x
+	/* Add UART mapping for early debug. */
+
  	/* pageid fields */
-	lis	r3,UART0_IO_BASE@h
-	ori	r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_4K
+	lis	r3,PPC44x_EARLY_DEBUG_VIRTADDR@h
+	ori	r3,r3,PPC44x_TLB_VALID|PPC44x_TLB_TS|PPC44x_TLB_64K
 
 	/* xlat fields */
-	lis	r4,UART0_PHYS_IO_BASE@h		/* RPN depends on SoC */
-#ifndef CONFIG_440EP
-	ori	r4,r4,0x0001		/* ERPN is 1 for second 4GB page */
-#endif
+	lis	r4,CONFIG_PPC_EARLY_DEBUG_44x_PHYSADDR@h
+	ori	r4,r4,(CONFIG_PPC_EARLY_DEBUG_44x_PHYSADDR >> 32)
 
 	/* attrib fields */
-	li	r5,0
-	ori	r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_I | PPC44x_TLB_G)
-
-        li      r0,0                    /* TLB slot 0 */
+	li	r5,(PPC44x_TLB_SW|PPC44x_TLB_SR|PPC44x_TLB_I|PPC44x_TLB_G)
+        li      r0,62                    /* TLB slot 0 */
 
-	tlbwe	r3,r0,PPC44x_TLB_PAGEID	/* Load the pageid fields */
-	tlbwe	r4,r0,PPC44x_TLB_XLAT	/* Load the translation fields */
-	tlbwe	r5,r0,PPC44x_TLB_ATTRIB	/* Load the attrib/access fields */
+	tlbwe	r3,r0,PPC44x_TLB_PAGEID
+	tlbwe	r4,r0,PPC44x_TLB_XLAT
+	tlbwe	r5,r0,PPC44x_TLB_ATTRIB
 
 	/* Force context change */
 	isync
-#endif /* CONFIG_SERIAL_TEXT_DEBUG */
+#endif /* CONFIG_PPC_EARLY_DEBUG_44x */
 
 	/* Establish the interrupt vector offsets */
 	SET_IVOR(0,  CriticalInput);
Index: working-2.6/arch/powerpc/kernel/udbg_16550.c
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/udbg_16550.c	2007-02-09 09:57:55.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/udbg_16550.c	2007-02-09 11:51:03.000000000 +1100
@@ -191,3 +191,27 @@ void udbg_init_pas_realmode(void)
 	udbg_getc_poll = NULL;
 }
 #endif /* CONFIG_PPC_MAPLE */
+
+#ifdef CONFIG_PPC_EARLY_DEBUG_44x
+extern u8 as1_readb(volatile u8 __iomem  *addr);
+extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
+
+static void udbg_44x_as1_putc(char c)
+{
+	if (udbg_comport) {
+		while ((as1_readb(&udbg_comport->lsr) & LSR_THRE) == 0)
+			/* wait for idle */;
+		as1_writeb(c, &udbg_comport->thr); eieio();
+		if (c == '\n')
+			udbg_44x_as1_putc('\r');
+	}
+}
+
+void __init udbg_init_44x_as1(void)
+{
+	udbg_comport =
+		(volatile struct NS16550 __iomem *)PPC44x_EARLY_DEBUG_VIRTADDR;
+
+	udbg_putc = udbg_44x_as1_putc;
+}
+#endif /* CONFIG_PPC_EARLY_DEBUG_44x */
Index: working-2.6/include/asm-powerpc/mmu_44x.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/mmu_44x.h	2007-02-09 11:51:01.000000000 +1100
+++ working-2.6/include/asm-powerpc/mmu_44x.h	2007-02-09 11:51:03.000000000 +1100
@@ -68,7 +68,13 @@ typedef struct {
 #define PPC44x_PIN_SHIFT	28
 #define PPC_PIN_SIZE		(1 << PPC44x_PIN_SHIFT)
 
+#ifndef CONFIG_PPC_EARLY_DEBUG_44x
 #define PPC44x_EARLY_TLBS	1
+#else
+#define PPC44x_EARLY_TLBS	2
+#define PPC44x_EARLY_DEBUG_VIRTADDR	\
+	(ASM_CONST(0xf0000000) | (CONFIG_PPC_EARLY_DEBUG_44x_PHYSADDR & 0xffff))
+#endif
 
 #endif /* _ASM_POWERPC_MMU_44X_H_ */
 
Index: working-2.6/arch/powerpc/kernel/udbg.c
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/udbg.c	2007-02-09 11:50:17.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/udbg.c	2007-02-09 11:51:03.000000000 +1100
@@ -51,6 +51,9 @@ void __init udbg_early_init(void)
 	udbg_init_pas_realmode();
 #elif defined(CONFIG_BOOTX_TEXT)
 	udbg_init_btext();
+#elif defined(CONFIG_PPC_EARLY_DEBUG_44x)
+	/* PPC44x debug */
+	udbg_init_44x_as1();
 #endif
 }
 
Index: working-2.6/include/asm-powerpc/udbg.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/udbg.h	2007-02-09 11:50:41.000000000 +1100
+++ working-2.6/include/asm-powerpc/udbg.h	2007-02-09 11:51:03.000000000 +1100
@@ -47,6 +47,7 @@ extern void __init udbg_init_rtas_panel(
 extern void __init udbg_init_rtas_console(void);
 extern void __init udbg_init_debug_beat(void);
 extern void __init udbg_init_btext(void);
+extern void __init udbg_init_44x_as1(void);
 
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_UDBG_H */
Index: working-2.6/arch/powerpc/kernel/Makefile
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/Makefile	2007-02-09 11:50:54.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/Makefile	2007-02-09 11:51:03.000000000 +1100
@@ -54,6 +54,7 @@ obj-y				+= time.o prom.o traps.o setup-
 				   udbg.o misc.o io.o
 obj-$(CONFIG_PPC32)		+= entry_32.o setup_32.o misc_32.o
 obj-$(CONFIG_PPC64)		+= misc_64.o dma_64.o iommu.o
+obj-$(CONFIG_44x)		+= misc_44x.o
 obj-$(CONFIG_PPC_MULTIPLATFORM)	+= prom_init.o
 obj-$(CONFIG_MODULES)		+= ppc_ksyms.o
 obj-$(CONFIG_BOOTX_TEXT)	+= btext.o
Index: working-2.6/arch/powerpc/kernel/misc_44x.S
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ working-2.6/arch/powerpc/kernel/misc_44x.S	2007-02-09 11:51:03.000000000 +1100
@@ -0,0 +1,46 @@
+/*
+ * This file contains miscellaneous low-level functions for PPC 44x.
+ *    Copyright 2007 David Gibson <dwg@au1.ibm.com>, IBM Corporation.
+ *
+ * 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.
+ *
+ */
+
+#include <asm/reg.h>
+#include <asm/ppc_asm.h>
+
+	.text
+
+/*
+ * Do an IO access in AS1
+ */
+_GLOBAL(as1_readb)
+	mfmsr	r7
+	ori	r0,r7,MSR_DS
+	sync
+	mtmsr	r0
+	sync
+	isync
+	lbz	r3,0(r3)
+	sync
+	mtmsr	r7
+	sync
+	isync
+	blr
+
+_GLOBAL(as1_writeb)
+	mfmsr	r7
+	ori	r0,r7,MSR_DS
+	sync
+	mtmsr	r0
+	sync
+	isync
+	stb	r3,0(r4)
+	sync
+	mtmsr	r7
+	sync
+	isync
+	blr

Re: [PATCH 7/16] Early serial debug support for PPC44x

[Josh Boyer]

On Tue, 2007-02-13 at 17:10 +1100, David Gibson wrote:
> This patch adds support for early serial debugging via the built in
> port on IBM/AMCC PowerPC 44x CPUs.  It uses a bolted TLB entry in
> address space 1 for the UART's mapping, allowing robust debugging both
> before and after the initialization of the MMU.

When enabling this option, I get the following error:

 AS      arch/powerpc/kernel/head_44x.o
arch/powerpc/kernel/head_44x.S: Assembler messages:
arch/powerpc/kernel/head_44x.S:179: Warning: left operand is a bignum;
integer 0 assumed
arch/powerpc/kernel/head_44x.S:183: Error: bignum invalid
arch/powerpc/kernel/head_44x.S:184: Warning: left operand is a bignum;
integer 0 assumed
make[1]: *** [arch/powerpc/kernel/head_44x.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

josh

Re: [PATCH 7/16] Early serial debug support for PPC44x

[David Gibson]

On Tue, Feb 13, 2007 at 09:04:47AM -0600, Josh Boyer wrote:
> On Tue, 2007-02-13 at 17:10 +1100, David Gibson wrote:
> > This patch adds support for early serial debugging via the built in
> > port on IBM/AMCC PowerPC 44x CPUs.  It uses a bolted TLB entry in
> > address space 1 for the UART's mapping, allowing robust debugging both
> > before and after the initialization of the MMU.
> 
> When enabling this option, I get the following error:
> 
>  AS      arch/powerpc/kernel/head_44x.o
> arch/powerpc/kernel/head_44x.S: Assembler messages:
> arch/powerpc/kernel/head_44x.S:179: Warning: left operand is a bignum;
> integer 0 assumed
> arch/powerpc/kernel/head_44x.S:183: Error: bignum invalid
> arch/powerpc/kernel/head_44x.S:184: Warning: left operand is a bignum;
> integer 0 assumed
> make[1]: *** [arch/powerpc/kernel/head_44x.o] Error 1
> make: *** [arch/powerpc/kernel] Error 2

Um... works for me?  What version of the assembler are you using?

I'm using a 64-bit constant there, but for me at least the assembler
is able to handle manipulating it in constant expressions.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 7/16] Early serial debug support for PPC44x

[Josh Boyer]

On Wed, Feb 14, 2007 at 11:16:22AM +1100, David Gibson wrote:
> >  AS      arch/powerpc/kernel/head_44x.o
> > arch/powerpc/kernel/head_44x.S: Assembler messages:
> > arch/powerpc/kernel/head_44x.S:179: Warning: left operand is a bignum;
> > integer 0 assumed
> > arch/powerpc/kernel/head_44x.S:183: Error: bignum invalid
> > arch/powerpc/kernel/head_44x.S:184: Warning: left operand is a bignum;
> > integer 0 assumed
> > make[1]: *** [arch/powerpc/kernel/head_44x.o] Error 1
> > make: *** [arch/powerpc/kernel] Error 2
> 
> Um... works for me?  What version of the assembler are you using?
> 
> I'm using a 64-bit constant there, but for me at least the assembler
> is able to handle manipulating it in constant expressions.

[jwboyer@zod ~]$ powerpc-440-linux-gnu-as --version
GNU assembler 2.15

This is a crosstool built toolchain with binutils 2.15 and gcc 3.4.1.
Which versions are you using?

josh

Re: [PATCH 7/16] Early serial debug support for PPC44x

[David Gibson]

On Tue, Feb 13, 2007 at 07:02:36PM -0600, Josh Boyer wrote:
> On Wed, Feb 14, 2007 at 11:16:22AM +1100, David Gibson wrote:
> > >  AS      arch/powerpc/kernel/head_44x.o
> > > arch/powerpc/kernel/head_44x.S: Assembler messages:
> > > arch/powerpc/kernel/head_44x.S:179: Warning: left operand is a bignum;
> > > integer 0 assumed
> > > arch/powerpc/kernel/head_44x.S:183: Error: bignum invalid
> > > arch/powerpc/kernel/head_44x.S:184: Warning: left operand is a bignum;
> > > integer 0 assumed
> > > make[1]: *** [arch/powerpc/kernel/head_44x.o] Error 1
> > > make: *** [arch/powerpc/kernel] Error 2
> > 
> > Um... works for me?  What version of the assembler are you using?
> > 
> > I'm using a 64-bit constant there, but for me at least the assembler
> > is able to handle manipulating it in constant expressions.
> 
> [jwboyer@zod ~]$ powerpc-440-linux-gnu-as --version
> GNU assembler 2.15
> 
> This is a crosstool built toolchain with binutils 2.15 and gcc 3.4.1.
> Which versions are you using?

Hmm.. I appear to have binutils-2.17.  That could be it.

It would be nice to support the older binutils too, but I'm not sure
how to get around this without considerable inconvenience.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 7/16] Early serial debug support for PPC44x

[Alan Modra]

On Wed, Feb 14, 2007 at 12:00:44PM +1100, David Gibson wrote:
> On Tue, Feb 13, 2007 at 07:02:36PM -0600, Josh Boyer wrote:
> > On Wed, Feb 14, 2007 at 11:16:22AM +1100, David Gibson wrote:
> > > I'm using a 64-bit constant there, but for me at least the assembler
> > > is able to handle manipulating it in constant expressions.
> > 
> > [jwboyer@zod ~]$ powerpc-440-linux-gnu-as --version
> > GNU assembler 2.15
> > 
> > This is a crosstool built toolchain with binutils 2.15 and gcc 3.4.1.
> > Which versions are you using?
> 
> Hmm.. I appear to have binutils-2.17.  That could be it.
> 
> It would be nice to support the older binutils too, but I'm not sure
> how to get around this without considerable inconvenience.

I would guess that this isn't a matter of how old the assembler is,
but how the assembler was built.  If built on a 32-bit host with no
64-bit targets supported, then most internal assembler variables
are 32-bit and 64-bit constants are not handled very well.

You probably should avoid 64-bit expressions on a 32-bit target.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [PATCH 7/16] Early serial debug support for PPC44x

[David Gibson]

On Wed, Feb 14, 2007 at 12:30:12PM +1030, Alan Modra wrote:
> On Wed, Feb 14, 2007 at 12:00:44PM +1100, David Gibson wrote:
> > On Tue, Feb 13, 2007 at 07:02:36PM -0600, Josh Boyer wrote:
> > > On Wed, Feb 14, 2007 at 11:16:22AM +1100, David Gibson wrote:
> > > > I'm using a 64-bit constant there, but for me at least the assembler
> > > > is able to handle manipulating it in constant expressions.
> > > 
> > > [jwboyer@zod ~]$ powerpc-440-linux-gnu-as --version
> > > GNU assembler 2.15
> > > 
> > > This is a crosstool built toolchain with binutils 2.15 and gcc 3.4.1.
> > > Which versions are you using?
> > 
> > Hmm.. I appear to have binutils-2.17.  That could be it.
> > 
> > It would be nice to support the older binutils too, but I'm not sure
> > how to get around this without considerable inconvenience.
> 
> I would guess that this isn't a matter of how old the assembler is,
> but how the assembler was built.  If built on a 32-bit host with no
> 64-bit targets supported, then most internal assembler variables
> are 32-bit and 64-bit constants are not handled very well.
> 
> You probably should avoid 64-bit expressions on a 32-bit target.

Well, yes, but how.  This 32-bit target has 36-bit physical
addresses.  All those expressions do is pull the high and low 32-bit
words from literals.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 7/16] Early serial debug support for PPC44x

[Alan Modra]

On Wed, Feb 14, 2007 at 01:02:51PM +1100, David Gibson wrote:
> On Wed, Feb 14, 2007 at 12:30:12PM +1030, Alan Modra wrote:
> > On Wed, Feb 14, 2007 at 12:00:44PM +1100, David Gibson wrote:
> > > On Tue, Feb 13, 2007 at 07:02:36PM -0600, Josh Boyer wrote:
> > > > On Wed, Feb 14, 2007 at 11:16:22AM +1100, David Gibson wrote:
> > > > > I'm using a 64-bit constant there, but for me at least the assembler
> > > > > is able to handle manipulating it in constant expressions.
> > > > 
> > > > [jwboyer@zod ~]$ powerpc-440-linux-gnu-as --version
> > > > GNU assembler 2.15
> > > > 
> > > > This is a crosstool built toolchain with binutils 2.15 and gcc 3.4.1.
> > > > Which versions are you using?
> > > 
> > > Hmm.. I appear to have binutils-2.17.  That could be it.
> > > 
> > > It would be nice to support the older binutils too, but I'm not sure
> > > how to get around this without considerable inconvenience.
> > 
> > I would guess that this isn't a matter of how old the assembler is,
> > but how the assembler was built.  If built on a 32-bit host with no
> > 64-bit targets supported, then most internal assembler variables
> > are 32-bit and 64-bit constants are not handled very well.
> > 
> > You probably should avoid 64-bit expressions on a 32-bit target.
> 
> Well, yes, but how.

No idea, but I haven't even looked at the code in question.  I'm just
pointing out the toolchain limitation.  It sounds like what you've
done requires that people build their binutils with
--enable-64-bit-bfd or choose support for an extra 64-bit target,
eg. --enable-targets=powerpc64-linux

>  This 32-bit target has 36-bit physical
> addresses.  All those expressions do is pull the high and low 32-bit
> words from literals.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [PATCH 7/16] Early serial debug support for PPC44x

[Josh Boyer]

On Wed, 2007-02-14 at 13:08 +1030, Alan Modra wrote:
> > > 
> > > I would guess that this isn't a matter of how old the assembler is,
> > > but how the assembler was built.  If built on a 32-bit host with no
> > > 64-bit targets supported, then most internal assembler variables
> > > are 32-bit and 64-bit constants are not handled very well.
> > > 
> > > You probably should avoid 64-bit expressions on a 32-bit target.
> > 
> > Well, yes, but how.
> 
> No idea, but I haven't even looked at the code in question.  I'm just
> pointing out the toolchain limitation.  It sounds like what you've
> done requires that people build their binutils with
> --enable-64-bit-bfd or choose support for an extra 64-bit target,
> eg. --enable-targets=powerpc64-linux

Yes, that seems to be the case.  I built a powerpc64 cross toolchain
this morning and recompiled the kernel.  It worked just fine.

But I also think we want to avoid requiring that in peoples toolchains.
I'll see if we can't accomplish what we're trying to do some other way
without being too ugly.

josh

Re: [PATCH 7/16] Early serial debug support for PPC44x

[David Gibson]

On Wed, Feb 14, 2007 at 09:41:48AM -0600, Josh Boyer wrote:
> On Wed, 2007-02-14 at 13:08 +1030, Alan Modra wrote:
> > > > 
> > > > I would guess that this isn't a matter of how old the assembler is,
> > > > but how the assembler was built.  If built on a 32-bit host with no
> > > > 64-bit targets supported, then most internal assembler variables
> > > > are 32-bit and 64-bit constants are not handled very well.
> > > > 
> > > > You probably should avoid 64-bit expressions on a 32-bit target.
> > > 
> > > Well, yes, but how.
> > 
> > No idea, but I haven't even looked at the code in question.  I'm just
> > pointing out the toolchain limitation.  It sounds like what you've
> > done requires that people build their binutils with
> > --enable-64-bit-bfd or choose support for an extra 64-bit target,
> > eg. --enable-targets=powerpc64-linux
> 
> Yes, that seems to be the case.  I built a powerpc64 cross toolchain
> this morning and recompiled the kernel.  It worked just fine.
> 
> But I also think we want to avoid requiring that in peoples toolchains.
> I'll see if we can't accomplish what we're trying to do some other way
> without being too ugly.

Ugh.  Yeah, we're going to have to do something.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[PATCH 2/16] More DCR native fixups

[David Gibson]

Getting BenH's new EMAC driver working on 440GP, I found some more
problems in the native mode paths of the new DCR code.  Here's a fix.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 include/asm-powerpc/dcr-native.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: working-2.6/include/asm-powerpc/dcr-native.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/dcr-native.h	2007-02-09 13:59:07.000000000 +1100
+++ working-2.6/include/asm-powerpc/dcr-native.h	2007-02-09 13:59:36.000000000 +1100
@@ -26,8 +26,8 @@ typedef struct {} dcr_host_t;
 
 #define DCR_MAP_OK(host)	(1)
 
-#define dcr_map(dev, dcr_n, dcr_c)	{}
-#define dcr_unmap(host, dcr_n, dcr_c)	{}
+#define dcr_map(dev, dcr_n, dcr_c)	((dcr_host_t){})
+#define dcr_unmap(host, dcr_n, dcr_c)	do {} while (0)
 #define dcr_read(host, dcr_n)		mfdcr(dcr_n)
 #define dcr_write(host, dcr_n, value)	mtdcr(dcr_n, value)
 

Re: [PATCH 2/16] More DCR native fixups

[Benjamin Herrenschmidt]

On Tue, 2007-02-13 at 17:10 +1100, David Gibson wrote:
> Getting BenH's new EMAC driver working on 440GP, I found some more
> problems in the native mode paths of the new DCR code.  Here's a fix.
> 
> Signed-off-by: David Gibson <dwg@au1.ibm.com>

Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

> ---
> 
>  include/asm-powerpc/dcr-native.h |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Index: working-2.6/include/asm-powerpc/dcr-native.h
> ===================================================================
> --- working-2.6.orig/include/asm-powerpc/dcr-native.h	2007-02-09 13:59:07.000000000 +1100
> +++ working-2.6/include/asm-powerpc/dcr-native.h	2007-02-09 13:59:36.000000000 +1100
> @@ -26,8 +26,8 @@ typedef struct {} dcr_host_t;
>  
>  #define DCR_MAP_OK(host)	(1)
>  
> -#define dcr_map(dev, dcr_n, dcr_c)	{}
> -#define dcr_unmap(host, dcr_n, dcr_c)	{}
> +#define dcr_map(dev, dcr_n, dcr_c)	((dcr_host_t){})
> +#define dcr_unmap(host, dcr_n, dcr_c)	do {} while (0)
>  #define dcr_read(host, dcr_n)		mfdcr(dcr_n)
>  #define dcr_write(host, dcr_n, value)	mtdcr(dcr_n, value)
>  
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 1/16] Remove ibm4{xx,4x}.h from arch/powerpc

[David Gibson]

ARCH=powerpc should not use the ghastly un-multiplatformable tangle of
includes that starts with asm-ppc/ibm4xx.h.  This patch removes a
compile-breaking include of it from head_44x.S.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/kernel/head_44x.S |    2 --
 1 file changed, 2 deletions(-)

Index: working-2.6/arch/powerpc/kernel/head_44x.S
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/head_44x.S	2007-01-12 17:22:42.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/head_44x.S	2007-01-12 17:37:39.000000000 +1100
@@ -32,8 +32,6 @@
 #include <asm/page.h>
 #include <asm/mmu.h>
 #include <asm/pgtable.h>
-#include <asm/ibm4xx.h>
-#include <asm/ibm44x.h>
 #include <asm/cputable.h>
 #include <asm/thread_info.h>
 #include <asm/ppc_asm.h>

Re: [PATCH 1/16] Remove ibm4{xx,4x}.h from arch/powerpc

[Josh Boyer]

On Tue, 2007-02-13 at 17:10 +1100, David Gibson wrote:
> ARCH=powerpc should not use the ghastly un-multiplatformable tangle of
> includes that starts with asm-ppc/ibm4xx.h.  This patch removes a
> compile-breaking include of it from head_44x.S.

This one is in paulus' tree.  Just an FYI for those wanting to try
these.

josh

[PATCH 10/16] Add support for BSS stack for zImage wrapper

[David Gibson]

Some embedded powerpc firmwares don't set up a stack before the zImage
wrapper enters, or set up a stack at an address which is not usable
for some reason.  This patch provides an (optional) alternate,
fixed-size stack included in the zImage's BSS area.  Platforms which
need their own stack can use the USE_BSS_STACK macro in their platform
.o files to force the BSS stack to be used instead of assuming that r1
contains a usable stack pointer on entry.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/boot/Makefile    |    2 +-
 arch/powerpc/boot/bss_stack.S |   17 +++++++++++++++++
 arch/powerpc/boot/crt0.S      |   11 +++++++++--
 arch/powerpc/boot/ops.h       |    3 +++
 4 files changed, 30 insertions(+), 3 deletions(-)

Index: working-2.6/arch/powerpc/boot/bss_stack.S
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ working-2.6/arch/powerpc/boot/bss_stack.S	2007-02-06 13:49:05.000000000 +1100
@@ -0,0 +1,17 @@
+/*
+ * Copyright 2007 David Gibson, IBM Corporation.  <dwg@au1.ibm.com>
+ *
+ * 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.
+ *
+ * NOTE: this code runs in 32 bit mode and is packaged as ELF32.
+ */
+
+	.section ".bss"
+	.weak	_bss_stack, _bss_stack_top
+	.globl	_bss_stack, _bss_stack_top
+_bss_stack:
+	.space	4096
+_bss_stack_top:
Index: working-2.6/arch/powerpc/boot/crt0.S
===================================================================
--- working-2.6.orig/arch/powerpc/boot/crt0.S	2007-02-06 13:48:27.000000000 +1100
+++ working-2.6/arch/powerpc/boot/crt0.S	2007-02-06 14:04:28.000000000 +1100
@@ -11,6 +11,8 @@
 
 #include "ppc_asm.h"
 
+	.weak	_bss_stack_top
+
 	.text
 	/* a procedure descriptor used when booting this as a COFF file */
 _zimage_start_opd:
@@ -59,6 +61,11 @@ _zimage_start:
 	sync
 	isync
 
-	mr	r6,r1
-	b	start
+	lis	r6,_bss_stack_top@ha
+	addi	r6,r6,_bss_stack_top@l
+	cmpwi	r6,0
+	beq	5f
+	mr	r1,r6
 
+5:	mr	r6,r1
+	b	start
Index: working-2.6/arch/powerpc/boot/Makefile
===================================================================
--- working-2.6.orig/arch/powerpc/boot/Makefile	2007-02-06 13:48:27.000000000 +1100
+++ working-2.6/arch/powerpc/boot/Makefile	2007-02-06 14:15:08.000000000 +1100
@@ -41,7 +41,7 @@ $(addprefix $(obj)/,$(zlib) main.o): $(a
 		$(addprefix $(obj)/,$(zlibheader))
 
 src-wlib := string.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
-		ns16550.c serial.c simple_alloc.c div64.S util.S $(zlib)
+		ns16550.c serial.c simple_alloc.c div64.S util.S bss_stack.S $(zlib)
 src-plat := of.c
 src-boot := crt0.S $(src-wlib) $(src-plat) empty.c
 
Index: working-2.6/arch/powerpc/boot/ops.h
===================================================================
--- working-2.6.orig/arch/powerpc/boot/ops.h	2007-02-06 14:14:00.000000000 +1100
+++ working-2.6/arch/powerpc/boot/ops.h	2007-02-06 14:15:45.000000000 +1100
@@ -100,4 +100,7 @@ static inline void exit(void)
 	for(;;);
 }
 
+extern char _bss_stack[], _bss_stack_top[];
+#define USE_BSS_STACK	void *_bss_stack_ptr = &_bss_stack_top
+
 #endif /* _PPC_BOOT_OPS_H_ */

[PATCH 9/16] Use resource_size_t for serial port IO addresses

[David Gibson]

At present, various parts of the serial code use unsigned long to
define resource addresses.  This is a problem, because some 32-bit
platforms have physical addresses larger than 32-bits, and have mmio
serial uarts located above the 4GB point.

This patch changes the type of mapbase in both struct uart_port and
struct plat_serial8250_port to resource_size_t, which can be
configured to be 64 bits on such platforms.  The mapbase in
serial_struct can't safely be changed, that structure is user visible.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 drivers/serial/8250.c        |    5 +++--
 drivers/serial/8250_early.c  |   16 +++++++++-------
 drivers/serial/serial_core.c |    9 +++++----
 include/linux/serial_8250.h  |    2 +-
 include/linux/serial_core.h  |    2 +-
 5 files changed, 19 insertions(+), 15 deletions(-)

Index: working-2.6/include/linux/serial_core.h
===================================================================
--- working-2.6.orig/include/linux/serial_core.h	2007-02-05 15:21:40.000000000 +1100
+++ working-2.6/include/linux/serial_core.h	2007-02-05 15:21:40.000000000 +1100
@@ -273,7 +273,7 @@ struct uart_port {
 	const struct uart_ops	*ops;
 	unsigned int		custom_divisor;
 	unsigned int		line;			/* port index */
-	unsigned long		mapbase;		/* for ioremap */
+	resource_size_t		mapbase;		/* for ioremap */
 	struct device		*dev;			/* parent device */
 	unsigned char		hub6;			/* this should be in the 8250 driver */
 	unsigned char		unused[3];
Index: working-2.6/drivers/serial/serial_core.c
===================================================================
--- working-2.6.orig/drivers/serial/serial_core.c	2007-02-05 15:21:40.000000000 +1100
+++ working-2.6/drivers/serial/serial_core.c	2007-02-05 15:21:40.000000000 +1100
@@ -633,7 +633,7 @@ static int uart_get_info(struct uart_sta
 	tmp.hub6	    = port->hub6;
 	tmp.io_type         = port->iotype;
 	tmp.iomem_reg_shift = port->regshift;
-	tmp.iomem_base      = (void *)port->mapbase;
+	tmp.iomem_base      = (void *)(unsigned long)port->mapbase;
 
 	if (copy_to_user(retinfo, &tmp, sizeof(*retinfo)))
 		return -EFAULT;
@@ -1673,10 +1673,11 @@ static int uart_line_info(char *buf, str
 		return 0;
 
 	mmio = port->iotype >= UPIO_MEM;
-	ret = sprintf(buf, "%d: uart:%s %s%08lX irq:%d",
+	ret = sprintf(buf, "%d: uart:%s %s%08llX irq:%d",
 			port->line, uart_type(port),
 			mmio ? "mmio:0x" : "port:",
-			mmio ? port->mapbase : (unsigned long) port->iobase,
+			mmio ? (unsigned long long)port->mapbase
+		             : (unsigned long long) port->iobase,
 			port->irq);
 
 	if (port->type == PORT_UNKNOWN) {
@@ -2062,7 +2063,7 @@ uart_report_port(struct uart_driver *drv
 	case UPIO_AU:
 	case UPIO_TSI:
 		snprintf(address, sizeof(address),
-			 "MMIO 0x%lx", port->mapbase);
+			 "MMIO 0x%llx", (unsigned long long)port->mapbase);
 		break;
 	default:
 		strlcpy(address, "*unknown*", sizeof(address));
Index: working-2.6/drivers/serial/8250_early.c
===================================================================
--- working-2.6.orig/drivers/serial/8250_early.c	2007-02-05 15:20:46.000000000 +1100
+++ working-2.6/drivers/serial/8250_early.c	2007-02-05 15:21:40.000000000 +1100
@@ -145,8 +145,9 @@ static int __init parse_options(struct e
 		port->mapbase = simple_strtoul(options + 5, &options, 0);
 		port->membase = ioremap(port->mapbase, mapsize);
 		if (!port->membase) {
-			printk(KERN_ERR "%s: Couldn't ioremap 0x%lx\n",
-				__FUNCTION__, port->mapbase);
+			printk(KERN_ERR "%s: Couldn't ioremap 0x%llx\n",
+				__FUNCTION__,
+			       (unsigned long long)port->mapbase);
 			return -ENOMEM;
 		}
 		mmio = 1;
@@ -168,9 +169,10 @@ static int __init parse_options(struct e
 			device->baud);
 	}
 
-	printk(KERN_INFO "Early serial console at %s 0x%lx (options '%s')\n",
+	printk(KERN_INFO "Early serial console at %s 0x%llx (options '%s')\n",
 		mmio ? "MMIO" : "I/O port",
-		mmio ? port->mapbase : (unsigned long) port->iobase,
+		mmio ? (unsigned long long) port->mapbase
+	             : (unsigned long long) port->iobase,
 		device->options);
 	return 0;
 }
@@ -236,10 +238,10 @@ static int __init early_uart_console_swi
 	mmio = (port->iotype == UPIO_MEM);
 	line = serial8250_start_console(port, device->options);
 	if (line < 0)
-		printk("No ttyS device at %s 0x%lx for console\n",
+		printk("No ttyS device at %s 0x%llx for console\n",
 			mmio ? "MMIO" : "I/O port",
-			mmio ? port->mapbase :
-			    (unsigned long) port->iobase);
+			mmio ? (unsigned long long) port->mapbase
+		             : (unsigned long long) port->iobase);
 
 	unregister_console(&early_uart_console);
 	if (mmio)
Index: working-2.6/include/linux/serial_8250.h
===================================================================
--- working-2.6.orig/include/linux/serial_8250.h	2007-02-05 15:20:46.000000000 +1100
+++ working-2.6/include/linux/serial_8250.h	2007-02-05 15:21:40.000000000 +1100
@@ -20,7 +20,7 @@
 struct plat_serial8250_port {
 	unsigned long	iobase;		/* io base address */
 	void __iomem	*membase;	/* ioremap cookie or NULL */
-	unsigned long	mapbase;	/* resource base */
+	resource_size_t	mapbase;	/* resource base */
 	unsigned int	irq;		/* interrupt number */
 	unsigned int	uartclk;	/* UART clock rate */
 	unsigned char	regshift;	/* register shift */
Index: working-2.6/drivers/serial/8250.c
===================================================================
--- working-2.6.orig/drivers/serial/8250.c	2007-02-05 15:24:16.000000000 +1100
+++ working-2.6/drivers/serial/8250.c	2007-02-05 15:24:34.000000000 +1100
@@ -2456,8 +2456,9 @@ static int __devinit serial8250_probe(st
 		ret = serial8250_register_port(&port);
 		if (ret < 0) {
 			dev_err(&dev->dev, "unable to register port at index %d "
-				"(IO%lx MEM%lx IRQ%d): %d\n", i,
-				p->iobase, p->mapbase, p->irq, ret);
+				"(IO%lx MEM%llx IRQ%d): %d\n", i,
+				p->iobase, (unsigned long long)p->mapbase,
+				p->irq, ret);
 		}
 	}
 	return 0;

[PATCH 13/16] Add initrd properties to device tree from zImage

[David Gibson]

Current kernels expect the address of an initrd to be passed via
properties in the /chosen node of the device tree.  However, so far
the zImage wrapper code does not add these properties to the device
tree and will only pass initrd information to the kernel via the older
OF method.

This patch fixes that deficiency.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/boot/main.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

Index: working-2.6/arch/powerpc/boot/main.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/main.c	2007-02-09 15:17:15.000000000 +1100
+++ working-2.6/arch/powerpc/boot/main.c	2007-02-09 15:25:03.000000000 +1100
@@ -172,6 +172,7 @@ static int is_elf32(void *hdr)
 static void prep_kernel(unsigned long a1, unsigned long a2)
 {
 	int len;
+	void *devp;
 
 	vmlinuz.addr = (unsigned long)_vmlinux_start;
 	vmlinuz.size = (unsigned long)(_vmlinux_end - _vmlinux_start);
@@ -236,6 +237,18 @@ static void prep_kernel(unsigned long a1
 		       initrd.addr, initrd.size);
 	}
 
+	/* Tell the kernel initrd address via device tree */
+	if (initrd.size && (devp = finddevice("/chosen"))) {
+		u32 initrd_start = initrd.addr;
+		u32 initrd_end = initrd.addr + initrd.size;
+
+		setprop(devp, "linux,initrd-start", &initrd_start,
+			sizeof(initrd_start));
+		setprop(devp, "linux,initrd-end", &initrd_end,
+			sizeof(initrd_end));
+	}
+
+
 	/* Eventually gunzip the kernel */
 	if (*(unsigned short *)vmlinuz.addr == 0x1f8b) {
 		printf("gunzipping (0x%lx <- 0x%lx:0x%0lx)...",

[PATCH 11/16] zImage wrapper for Ebony

[David Gibson]

This patch adds support for building a zImage wrapper suitable for the
Ebony (440GP) evaluation board.  This supports booting both from uboot
(old versions which don't supply a flattened device tree) and IBM
Openbios (aka "treeboot").

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/boot/Makefile |   33 ++++++++++++++++++++++++++++++++-
 arch/powerpc/boot/ebony.c  |   43 +++++++++++++++++++++++++++++++++++++++++++
 arch/powerpc/boot/mktree.c |   10 ++++------
 arch/powerpc/boot/wrapper  |   33 +++++++++++++++++++++++++++++++++
 4 files changed, 112 insertions(+), 7 deletions(-)

Index: working-2.6/arch/powerpc/boot/Makefile
===================================================================
--- working-2.6.orig/arch/powerpc/boot/Makefile	2007-02-12 14:22:17.000000000 +1100
+++ working-2.6/arch/powerpc/boot/Makefile	2007-02-12 14:22:17.000000000 +1100
@@ -42,7 +42,7 @@ $(addprefix $(obj)/,$(zlib) main.o): $(a
 
 src-wlib := string.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
 		ns16550.c serial.c simple_alloc.c div64.S util.S bss_stack.S $(zlib)
-src-plat := of.c
+src-plat := of.c ebony.c
 src-boot := crt0.S $(src-wlib) $(src-plat) empty.c
 
 src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -94,6 +94,12 @@ $(patsubst %.S,%.o, $(filter %.S, $(src-
 $(obj)/wrapper.a: $(obj-wlib)
 	$(call cmd,bootar)
 
+quiet_cmd_dtc = DTC     $@
+      cmd_dtc = $(dtc) -O dtb -o $@ -b 0 -V 16 $<
+
+$(obj)/%.dtb: $(srctree)/$(src)/dts/%.dts
+	$(call if_changed,dtc)
+
 hostprogs-y	:= addnote addRamDisk hack-coff mktree
 
 extra-y		:= $(obj)/crt0.o $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \
@@ -102,6 +108,8 @@ extra-y		:= $(obj)/crt0.o $(obj)/wrapper
 wrapper		:=$(srctree)/$(src)/wrapper
 wrapperbits	:= $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree)
 
+dtc		:= dtc
+
 #############
 # Bits for building various flavours of zImage
 
@@ -119,6 +127,13 @@ quiet_cmd_wrap_initrd = WRAP    $@
       cmd_wrap_initrd =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
 				-i $(obj)/ramdisk.image.gz vmlinux
 
+quiet_cmd_wrap_dtb	= WRAP    $@
+      cmd_wrap_dtb	=$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
+				-d $3 vmlinux
+quiet_cmd_wrap_dtb_initrd = WRAP    $@
+      cmd_wrap_dtb_initrd =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
+				-d $3 -i $(obj)/ramdisk.image.gz vmlinux
+
 $(obj)/zImage.chrp: vmlinux $(wrapperbits)
 	$(call cmd,wrap,chrp)
 
@@ -155,6 +170,21 @@ $(obj)/zImage.ps3: vmlinux
 $(obj)/zImage.initrd.ps3: vmlinux
 	@echo "  WARNING zImage.initrd.ps3 not supported (yet)"
 
+$(obj)/zImage.ebony-elf: vmlinux $(wrapperbits) $(obj)/ebony.dtb
+	$(call cmd,wrap_dtb,ebony,$(obj)/ebony.dtb)
+
+$(obj)/zImage.initrd.ebony-elf: vmlinux $(wrapperbits) $(obj)/ebony.dtb $(obj)/ramdisk.image.gz
+	$(call cmd,wrap_dtb_initrd,ebony,$(obj)/ebony.dtb)
+
+$(obj)/zImage.ebony: vmlinux $(wrapperbits) $(obj)/ebony.dtb $(obj)/mktree
+	$(call cmd,wrap_dtb,ebony-tree,$(obj)/ebony.dtb)
+
+$(obj)/zImage.initrd.ebony: vmlinux $(wrapperbits) $(obj)/ebony.dtb $(obj)/mktree
+	$(call cmd,wrap_dtb_initrd,ebony-tree,$(obj)/ebony.dtb)
+
+$(obj)/uImage.ebony: vmlinux $(wrapperbits)  $(obj)/ebony.dtb
+	$(call cmd,wrap_dtb,ebony-uboot,$(obj)/ebony.dtb)
+
 $(obj)/uImage: vmlinux $(wrapperbits)
 	$(call cmd,wrap,uboot)
 
@@ -166,6 +196,7 @@ image-$(CONFIG_PPC_CELLEB)		+= zImage.ps
 image-$(CONFIG_PPC_CHRP)		+= zImage.chrp
 image-$(CONFIG_PPC_EFIKA)		+= zImage.chrp
 image-$(CONFIG_PPC_PMAC)		+= zImage.pmac
+image-$(CONFIG_EBONY)			+= zImage.ebony-elf zImage.ebony uImage.ebony
 image-$(CONFIG_DEFAULT_UIMAGE)		+= uImage
 
 # For 32-bit powermacs, build the COFF and miboot images
Index: working-2.6/arch/powerpc/boot/ebony.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ working-2.6/arch/powerpc/boot/ebony.c	2007-02-12 14:22:17.000000000 +1100
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) Paul Mackerras 1997.
+ *
+ * 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.
+ */
+#include <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "elf.h"
+#include "string.h"
+#include "stdio.h"
+#include "page.h"
+#include "ops.h"
+
+extern char _start[];
+extern char _end[];
+
+USE_BSS_STACK;
+
+static unsigned long ebony_vmlinux_addr(unsigned long size)
+{
+	if ((unsigned long)_start < size) {
+		printf("Insufficient memory for kernel at address 0! (_start=%lx)\n\r",
+		       _start);
+		exit();
+	}
+	return 0;
+}
+
+int platform_init(void *promptr, char *dt_blob_start, char *dt_blob_end)
+{
+	u32 heapsize = 0x8000000 - (u32)_end; /* 128M */
+
+	simple_alloc_init(_end, heapsize, 32, 64);
+	ft_init(dt_blob_start, 0, 4);
+	serial_console_init();
+	platform_ops.vmlinux_addr = ebony_vmlinux_addr;
+
+	return 0;
+}
Index: working-2.6/arch/powerpc/boot/wrapper
===================================================================
--- working-2.6.orig/arch/powerpc/boot/wrapper	2007-01-24 12:01:17.000000000 +1100
+++ working-2.6/arch/powerpc/boot/wrapper	2007-02-12 14:22:17.000000000 +1100
@@ -137,6 +137,12 @@ miboot|uboot)
     ksection=image
     isection=initrd
     ;;
+*-tree)
+    platformo=$object/"${platform%%-tree}".o
+    ;;
+*-uboot)
+    platformo=$object/"${platform%%-uboot}".o
+    ;;
 esac
 
 vmz="$tmpdir/`basename \"$kernel\"`.$ext"
@@ -204,4 +210,31 @@ pmaccoff)
     ${CROSS}objcopy -O aixcoff-rs6000 --set-start 0x500000 "$ofile"
     $object/hack-coff "$ofile"
     ;;
+*-tree)
+    mv "$ofile" "$ofile.elf"
+    entry=`objdump -f "$ofile.elf" | grep '^start address ' | \
+	cut -d' ' -f3`
+    $object/mktree "$ofile.elf" "$ofile" 0x00400000 "$entry"
+    if [ -z "$cacheit" ]; then
+	rm -f "$ofile.elf"
+    fi
+    exit 0
+    ;;
+*-uboot)
+    mv "$ofile" "$ofile.elf"
+    version=`${CROSS}strings "$kernel" | grep '^Linux version [-0-9.]' | \
+	cut -d' ' -f3`
+    if [ -n "$version" ]; then
+	version="-n Linux-$version"
+    fi
+    entry=`objdump -f "$ofile.elf" | grep '^start address ' | \
+	cut -d' ' -f3`
+    ${CROSS}objcopy -O binary "$ofile.elf" "$ofile.bin"
+    mkimage -A ppc -O linux -T kernel -C none -a 0x00400000 -e $entry \
+	$version -d "$ofile.bin" "$ofile"
+    if [ -z "$cacheit" ]; then
+	rm -f "$ofile.elf" "$ofile.bin"
+    fi
+    exit 0
+    ;;
 esac
Index: working-2.6/arch/powerpc/boot/mktree.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/mktree.c	2007-01-24 12:01:17.000000000 +1100
+++ working-2.6/arch/powerpc/boot/mktree.c	2007-02-12 14:22:17.000000000 +1100
@@ -46,8 +46,8 @@ int main(int argc, char *argv[])
 	struct	stat	st;
 	boot_block_t	bt;
 
-	if (argc < 3) {
-		fprintf(stderr, "usage: %s <zImage-file> <boot-image> [entry-point]\n",argv[0]);
+	if (argc < 5) {
+		fprintf(stderr, "usage: %s <zImage-file> <boot-image> <load address> <entry point>\n",argv[0]);
 		exit(1);
 	}
 
@@ -61,10 +61,8 @@ int main(int argc, char *argv[])
 	bt.bb_magic = htonl(0x0052504F);
 
 	/* If we have the optional entry point parameter, use it */
-	if (argc == 4)
-		bt.bb_dest = bt.bb_entry_point = htonl(strtoul(argv[3], NULL, 0));
-	else
-		bt.bb_dest = bt.bb_entry_point = htonl(0x500000);
+	bt.bb_dest = htonl(strtoul(argv[3], NULL, 0));
+	bt.bb_entry_point = htonl(strtoul(argv[4], NULL, 0));
 
 	/* We know these from the linker command.
 	 * ...and then move it up into memory a little more so the

Re: [PATCH 11/16] zImage wrapper for Ebony

[Geoff Levand]

David Gibson wrote:
> This patch adds support for building a zImage wrapper suitable for the
> Ebony (440GP) evaluation board.  This supports booting both from uboot
> (old versions which don't supply a flattened device tree) and IBM
> Openbios (aka "treeboot").

> +++ working-2.6/arch/powerpc/boot/Makefile	2007-02-12 14:22:17.000000000 +1100
> -src-plat := of.c
> +src-plat := of.c ebony.c
>  src-boot := crt0.S $(src-wlib) $(src-plat) empty.c


Could this be better as:

src-plat-$(CONFIG_44x) += ebony.c
src-plat := of.c $(src-plat-y)


>  src-boot := $(addprefix $(obj)/, $(src-boot))
> @@ -94,6 +94,12 @@ $(patsubst %.S,%.o, $(filter %.S, $(src-
>  $(obj)/wrapper.a: $(obj-wlib)
>  	$(call cmd,bootar)
>  
> +quiet_cmd_dtc = DTC     $@
> +      cmd_dtc = $(dtc) -O dtb -o $@ -b 0 -V 16 $<
> +
> +$(obj)/%.dtb: $(srctree)/$(src)/dts/%.dts
> +	$(call if_changed,dtc)
> +


If dtc is not installed will this create an empty dtb file that ends
up getting used?  If so, try something like this:

cmd_dtc = $(dtc) -O dtb -o $@ -b 0 -V 16 $< $@.tmp && mv $@.tmp $@


I think you need to clean your dtb, so something like this also:

clean-files += $(obj)/%.dtb 


-Geoff

Re: [PATCH 11/16] zImage wrapper for Ebony

[David Gibson]

On Tue, Feb 13, 2007 at 09:05:00AM -0800, Geoff Levand wrote:
> David Gibson wrote:
> > This patch adds support for building a zImage wrapper suitable for the
> > Ebony (440GP) evaluation board.  This supports booting both from uboot
> > (old versions which don't supply a flattened device tree) and IBM
> > Openbios (aka "treeboot").
> 
> > +++ working-2.6/arch/powerpc/boot/Makefile	2007-02-12 14:22:17.000000000 +1100
> > -src-plat := of.c
> > +src-plat := of.c ebony.c
> >  src-boot := crt0.S $(src-wlib) $(src-plat) empty.c
> 
> 
> Could this be better as:
> 
> src-plat-$(CONFIG_44x) += ebony.c
> src-plat := of.c $(src-plat-y)
> 
> 
> >  src-boot := $(addprefix $(obj)/, $(src-boot))
> > @@ -94,6 +94,12 @@ $(patsubst %.S,%.o, $(filter %.S, $(src-
> >  $(obj)/wrapper.a: $(obj-wlib)
> >  	$(call cmd,bootar)
> >  
> > +quiet_cmd_dtc = DTC     $@
> > +      cmd_dtc = $(dtc) -O dtb -o $@ -b 0 -V 16 $<
> > +
> > +$(obj)/%.dtb: $(srctree)/$(src)/dts/%.dts
> > +	$(call if_changed,dtc)
> > +
> 
> 
> If dtc is not installed will this create an empty dtb file that ends
> up getting used?  If so, try something like this:

Um.. no.  How would dtc create a file if it wasn't there..?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[PATCH 14/16] Add arch/powerpc driver for UIC, PPC4xx interrupt controller

[David Gibson]

This patch adds a driver to arch/powerpc/sysdev for the UIC, the
on-chip interrupt controller from IBM/AMCC 4xx chips.  It uses the new
irq host mapping infrastructure.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/sysdev/Makefile |    1 
 arch/powerpc/sysdev/uic.c    |  343 +++++++++++++++++++++++++++++++++++++++++++
 include/asm-powerpc/uic.h    |   23 ++
 3 files changed, 367 insertions(+)

Index: working-2.6/arch/powerpc/sysdev/uic.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ working-2.6/arch/powerpc/sysdev/uic.c	2007-02-12 14:30:31.000000000 +1100
@@ -0,0 +1,343 @@
+/*
+ * arch/powerpc/sysdev/uic.c
+ *
+ * IBM PowerPC 4xx Universal Interrupt Controller
+ *
+ * Copyright 2007 David Gibson <dwg@au1.ibm.com>, IBM Corporation.
+ *
+ * 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.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/reboot.h>
+#include <linux/slab.h>
+#include <linux/stddef.h>
+#include <linux/sched.h>
+#include <linux/signal.h>
+#include <linux/sysdev.h>
+#include <linux/device.h>
+#include <linux/bootmem.h>
+#include <linux/spinlock.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
+#include <asm/irq.h>
+#include <asm/io.h>
+#include <asm/prom.h>
+#include <asm/dcr.h>
+
+#define NR_UIC_INTS	32
+
+#define UIC_SR		0x0
+#define UIC_ER		0x2
+#define UIC_CR		0x3
+#define UIC_PR		0x4
+#define UIC_TR		0x5
+#define UIC_MSR		0x6
+#define UIC_VR		0x7
+#define UIC_VCR		0x8
+
+#define uic_irq_to_hw(virq)	(irq_map[virq].hwirq)
+
+struct uic *primary_uic;
+
+struct uic {
+	int index;
+	int dcrbase;
+
+	spinlock_t lock;
+
+	/* The remapper for this UIC */
+	struct irq_host	*irqhost;
+
+	/* For secondary UICs, the cascade interrupt's irqaction */
+	struct irqaction cascade;
+
+	/* The device node of the interrupt controller */
+	struct device_node *of_node;
+};
+
+static void uic_unmask_irq(unsigned int virq)
+{
+	struct uic *uic = get_irq_chip_data(virq);
+	unsigned int src = uic_irq_to_hw(virq);
+	unsigned long flags;
+	u32 er;
+
+	spin_lock_irqsave(&uic->lock, flags);
+	er = mfdcr(uic->dcrbase + UIC_ER);
+	er |= 1 << (31 - src);
+	mtdcr(uic->dcrbase + UIC_ER, er);
+	spin_unlock_irqrestore(&uic->lock, flags);
+}
+
+static void uic_mask_irq(unsigned int virq)
+{
+	struct uic *uic = get_irq_chip_data(virq);
+	unsigned int src = uic_irq_to_hw(virq);
+	unsigned long flags;
+	u32 er;
+
+	spin_lock_irqsave(&uic->lock, flags);
+	er = mfdcr(uic->dcrbase + UIC_ER);
+	er &= ~(1 << (31 - src));
+	mtdcr(uic->dcrbase + UIC_ER, er);
+	spin_unlock_irqrestore(&uic->lock, flags);
+}
+
+static void uic_ack_irq(unsigned int virq)
+{
+	struct uic *uic = get_irq_chip_data(virq);
+	unsigned int src = uic_irq_to_hw(virq);
+	unsigned long flags;
+
+	spin_lock_irqsave(&uic->lock, flags);
+	mtdcr(uic->dcrbase + UIC_SR, 1 << (31-src));
+	spin_unlock_irqrestore(&uic->lock, flags);
+}
+
+static int uic_set_irq_type(unsigned int virq, unsigned int flow_type)
+{
+	struct uic *uic = get_irq_chip_data(virq);
+	unsigned int src = uic_irq_to_hw(virq);
+	struct irq_desc *desc = get_irq_desc(virq);
+	unsigned long flags;
+	int trigger, polarity;
+	u32 tr, pr, mask;
+
+	switch (flow_type & IRQ_TYPE_SENSE_MASK) {
+	case IRQ_TYPE_NONE:
+		uic_mask_irq(virq);
+		return 0;
+
+	case IRQ_TYPE_EDGE_RISING:
+		trigger = 1; polarity = 1;
+		break;
+	case IRQ_TYPE_EDGE_FALLING:
+		trigger = 1; polarity = 0;
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+		trigger = 0; polarity = 1;
+		break;
+	case IRQ_TYPE_LEVEL_LOW:
+		trigger = 0; polarity = 1;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	mask = ~(1 << (31 - src));
+
+	spin_lock_irqsave(&uic->lock, flags);
+	tr = mfdcr(uic->dcrbase + UIC_TR);
+	pr = mfdcr(uic->dcrbase + UIC_PR);
+	tr = (tr & mask) | (trigger << (31-src));
+	pr = (pr & mask) | (polarity << (31-src));
+
+	mtdcr(uic->dcrbase + UIC_PR, pr);
+	mtdcr(uic->dcrbase + UIC_TR, tr);
+
+	desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
+	desc->status |= flow_type & IRQ_TYPE_SENSE_MASK;
+#if 0
+	/* In fact, handle_edge_irq() can handle UIC's edge
+	 * interrupts, too, because UIC doesn't lose edges detected
+	 * while the interrupt is masked.  FIXME: Check this is really
+	 * true */
+	if (trigger) {
+		set_irq_handler_locked(virq, handle_edge_irq, 0, "edge");
+	} else {
+		desc->status |= IRQ_LEVEL;
+		set_irq_handler_locked(virq, handle_level_irq, 0, "level");
+	}
+#endif
+
+	spin_unlock_irqrestore(&uic->lock, flags);
+
+	return 0;
+}
+
+static struct irq_chip uic_irq_chip = {
+	.typename	= " UIC  ",
+	.unmask		= uic_unmask_irq,
+	.mask		= uic_mask_irq,
+/* 	.mask_ack	= uic_mask_irq_and_ack, */
+	.ack		= uic_ack_irq,
+	.set_type	= uic_set_irq_type,
+};
+
+static int uic_host_match(struct irq_host *h, struct device_node *node)
+{
+	struct uic *uic = h->host_data;
+	return uic->of_node == node;
+}
+
+static int uic_host_map(struct irq_host *h, unsigned int virq,
+			irq_hw_number_t hw)
+{
+	struct uic *uic = h->host_data;
+
+	set_irq_chip_data(virq, uic);
+	set_irq_chip_and_handler(virq, &uic_irq_chip, handle_level_irq);
+
+	/* Set default irq type */
+	set_irq_type(virq, IRQ_TYPE_NONE);
+
+	return 0;
+}
+
+static int uic_host_xlate(struct irq_host *h, struct device_node *ct,
+			  u32 *intspec, unsigned int intsize,
+			  irq_hw_number_t *out_hwirq, unsigned int *out_type)
+
+{
+	/* UIC intspecs must have 2 cells */
+	BUG_ON(intsize != 2);
+	*out_hwirq = intspec[0];
+	*out_type = intspec[1];
+	return 0;
+}
+
+static struct irq_host_ops uic_host_ops = {
+	.match	= uic_host_match,
+	.map	= uic_host_map,
+	.xlate	= uic_host_xlate,
+};
+
+irqreturn_t uic_cascade(int virq, void *data)
+{
+	struct uic *uic = data;
+	u32 msr;
+	int src;
+	int subvirq;
+
+	msr = mfdcr(uic->dcrbase + UIC_MSR);
+	src = 32 - ffs(msr);
+
+	subvirq = irq_linear_revmap(uic->irqhost, src);
+	generic_handle_irq(subvirq);
+
+	return IRQ_HANDLED;
+}
+
+void __init uic_init_one(struct device_node *node)
+{
+	struct uic *uic;
+	const u32 *indexp, *dcrreg, *interrupts;
+	int len;
+
+	uic = alloc_bootmem(sizeof(*uic));
+	if (! uic)
+		return; /* FIXME: panic? */
+
+	memset(uic, 0, sizeof(*uic));
+	uic->of_node = of_node_get(node);
+	indexp = get_property(node, "cell-index", &len);
+	if (!indexp || (len != sizeof(u32))) {
+		printk(KERN_ERR "uic: Device node %s has missing or invalid "
+		       "cell-index property\n", node->full_name);
+		return;
+	}
+	uic->index = *indexp;
+
+	dcrreg = get_property(node, "dcr-reg", &len);
+	if (!dcrreg || (len != 2*sizeof(u32))) {
+		printk(KERN_ERR "uic: Device node %s has missing or invalid "
+		       "dcr-reg property\n", node->full_name);
+		return;
+	}
+	uic->dcrbase = *dcrreg;
+
+	uic->irqhost = irq_alloc_host(IRQ_HOST_MAP_LINEAR, NR_UIC_INTS,
+				      &uic_host_ops, -1);
+	if (! uic->irqhost) {
+		of_node_put(node);
+		return; /* FIXME: panic? */
+	}
+
+	uic->irqhost->host_data = uic;
+
+	/* Start with all interrupts disable and non-critical */
+	mtdcr(uic->dcrbase + UIC_ER, 0);
+	mtdcr(uic->dcrbase + UIC_CR, 0);
+
+	printk ("UIC%d (%d IRQ sources) at DCR 0x%x\n", uic->index,
+		NR_UIC_INTS, uic->dcrbase);
+
+	interrupts = get_property(node, "interrupts", &len);
+
+	if (! interrupts) {
+		/* This is the top level controller */
+		primary_uic = uic;
+		irq_set_default_host(primary_uic->irqhost);
+		return;
+	} else {
+		/* Secondary UIC */
+		int cascade_virq;
+		int ret;
+
+		cascade_virq = irq_of_parse_and_map(node, 0);
+
+		uic->cascade.handler = uic_cascade;
+		uic->cascade.name = "UIC cascade";
+		uic->cascade.dev_id = uic;
+
+		ret = setup_irq(cascade_virq, &uic->cascade);
+		if (ret)
+			printk(KERN_ERR "Failed to setup_irq(%d) for "
+			       "UIC%d cascade\n", cascade_virq, uic->index);
+
+		/* FIXME: setup critical cascade?? */
+	}
+}
+
+void __init uic_init_tree(void)
+{
+	const phandle *ic_phandle;
+	struct device_node *top, *sub, *prev;
+	int len;
+
+	ic_phandle = get_property(of_chosen, "interrupt-controller", &len);
+	if (!ic_phandle || (len != sizeof(*ic_phandle))) {
+		printk(KERN_CRIT "uic: Couldn't find interrupt-controller property "
+		       "in /chosen\n");
+		return;
+	}
+
+	top = of_find_node_by_phandle(*ic_phandle);
+	if (! top) {
+		printk(KERN_CRIT "uic: Couldn't find top-level UIC, phandle=%x\n",
+		       *ic_phandle);
+	}
+
+	uic_init_one(top);
+
+	prev = NULL;
+	while ((sub = of_get_next_child(top, prev)) != NULL) {
+		if (prev)
+			of_node_put(prev);
+
+		uic_init_one(sub);
+
+		prev = sub;
+	}
+
+	of_node_put(top);
+}
+
+/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */
+unsigned int uic_get_irq(void)
+{
+	u32 msr;
+	int src;
+
+	BUG_ON(primary_uic == NULL);
+
+	msr = mfdcr(primary_uic->dcrbase + UIC_MSR);
+	src = 32 - ffs(msr);
+
+	return irq_linear_revmap(primary_uic->irqhost, src);
+}
Index: working-2.6/arch/powerpc/sysdev/Makefile
===================================================================
--- working-2.6.orig/arch/powerpc/sysdev/Makefile	2007-02-09 09:57:55.000000000 +1100
+++ working-2.6/arch/powerpc/sysdev/Makefile	2007-02-12 14:22:17.000000000 +1100
@@ -16,6 +16,7 @@ obj-$(CONFIG_QUICC_ENGINE)	+= qe_lib/
 ifeq ($(CONFIG_PPC_MERGE),y)
 obj-$(CONFIG_PPC_I8259)		+= i8259.o
 obj-$(CONFIG_PPC_83xx)		+= ipic.o
+obj-$(CONFIG_4xx)		+= uic.o
 endif
 
 # Temporary hack until we have migrated to asm-powerpc
Index: working-2.6/include/asm-powerpc/uic.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ working-2.6/include/asm-powerpc/uic.h	2007-02-12 14:22:17.000000000 +1100
@@ -0,0 +1,23 @@
+/*
+ * include/asm-powerpc/uic.h
+ *
+ * IBM PPC4xx UIC external definitions and structure.
+ *
+ * Maintainer: David Gibson <dwg@au1.ibm.com>
+ * Copyright 2007 IBM Corporation.
+ *
+ * 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.
+ */
+#ifndef _ASM_POWERPC_UIC_H
+#define _ASM_POWERPC_UIC_H
+
+#ifdef __KERNEL__
+
+extern void __init uic_init_tree(void);
+extern unsigned int uic_get_irq(void);
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_UIC_H */

[PATCH 12/16] Automatically lmb_reserve() initrd

[David Gibson]

At present, when an initrd is passed to the kernel used flat device
tree properties, the memory the initrd occupies must also be reserved
in the flat tree's reserve map, or the kernel may overwrite it.  That
makes life more complicated than it could be for the bootwrapper.

This patch makes the kernel automatically reserve the initrd's space.
That in turn requires parsing the initrd parameters earlier than they
are currently, in early_init_dt_scan_chosen() instead of
check_for_initrd().

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/kernel/prom.c         |   23 +++++++++++++++++++++++
 arch/powerpc/kernel/setup-common.c |   22 ++--------------------
 2 files changed, 25 insertions(+), 20 deletions(-)

Index: working-2.6/arch/powerpc/kernel/prom.c
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/prom.c	2007-02-09 15:12:00.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/prom.c	2007-02-09 15:14:27.000000000 +1100
@@ -719,6 +719,7 @@ static int __init early_init_dt_scan_cho
 					    const char *uname, int depth, void *data)
 {
 	unsigned long *lprop;
+	u32 *prop;
 	unsigned long l;
 	char *p;
 
@@ -760,6 +761,22 @@ static int __init early_init_dt_scan_cho
                crashk_res.end = crashk_res.start + *lprop - 1;
 #endif
 
+#ifdef CONFIG_BLK_DEV_INITRD
+	DBG("Looking for initrd properties... ");
+	prop = of_get_flat_dt_prop(node, "linux,initrd-start", &l);
+	if (prop) {
+		initrd_start = (unsigned long)__va(of_read_ulong(prop, l/4));
+		prop = of_get_flat_dt_prop(node, "linux,initrd-end", &l);
+		if (prop) {
+			initrd_end = (unsigned long)__va(of_read_ulong(prop, l/4));
+			initrd_below_start_ok = 1;
+		} else {
+			initrd_start = 0;
+		}
+	}
+	DBG("initrd_start=0x%lx  initrd_end=0x%lx\n", initrd_start, initrd_end);
+#endif /* CONFIG_BLK_DEV_INITRD */
+
 	/* Retreive command line */
  	p = of_get_flat_dt_prop(node, "bootargs", &l);
 	if (p != NULL && l > 0)
@@ -926,6 +943,12 @@ static void __init early_reserve_mem(voi
 	self_size = initial_boot_params->totalsize;
 	lmb_reserve(self_base, self_size);
 
+#ifdef CONFIG_BLK_DEV_INITRD
+	/* then reserve the initrd, if any */
+	if (initrd_start && (initrd_end > initrd_start))
+		lmb_reserve(__pa(initrd_start), initrd_end - initrd_start);
+#endif /* CONFIG_BLK_DEV_INITRD */
+
 #ifdef CONFIG_PPC32
 	/* 
 	 * Handle the case where we might be booting from an old kexec
Index: working-2.6/arch/powerpc/kernel/setup-common.c
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/setup-common.c	2007-01-24 12:01:17.000000000 +1100
+++ working-2.6/arch/powerpc/kernel/setup-common.c	2007-02-09 15:15:15.000000000 +1100
@@ -304,26 +304,8 @@ struct seq_operations cpuinfo_op = {
 void __init check_for_initrd(void)
 {
 #ifdef CONFIG_BLK_DEV_INITRD
-	const unsigned int *prop;
-	int len;
-
-	DBG(" -> check_for_initrd()\n");
-
-	if (of_chosen) {
-		prop = get_property(of_chosen, "linux,initrd-start", &len);
-		if (prop != NULL) {
-			initrd_start = (unsigned long)
-				__va(of_read_ulong(prop, len / 4));
-			prop = get_property(of_chosen,
-					"linux,initrd-end", &len);
-			if (prop != NULL) {
-				initrd_end = (unsigned long)
-					__va(of_read_ulong(prop, len / 4));
-				initrd_below_start_ok = 1;
-			} else
-				initrd_start = 0;
-		}
-	}
+	DBG(" -> check_for_initrd()  initrd_start=0x%lx  initrd_end=0x%lx\n",
+	    initrd_start, initrd_end);
 
 	/* If we were passed an initrd, set the ROOT_DEV properly if the values
 	 * look sensible. If not, clear initrd reference.

Re: [PATCH 12/16] Automatically lmb_reserve() initrd

[Michael Neuling]

> At present, when an initrd is passed to the kernel used flat device
> tree properties, the memory the initrd occupies must also be reserved
> in the flat tree's reserve map, or the kernel may overwrite it.  That
> makes life more complicated than it could be for the bootwrapper.
> 
> This patch makes the kernel automatically reserve the initrd's space.
> That in turn requires parsing the initrd parameters earlier than they
> are currently, in early_init_dt_scan_chosen() instead of
> check_for_initrd().

Cool... this should remove some code in kexec-tools as well.

Mikey

[PATCH 15/16] Add device tree for Ebony

[David Gibson]

Add a device tree for the Ebony evaluation board (440GP based).  This
tree is not complete or finalized.  This tree needs a very recent
version of dtc to process.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/boot/dts/ebony.dts |  222 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 222 insertions(+)

Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts	2007-02-12 16:25:49.000000000 +1100
@@ -0,0 +1,222 @@
+/*
+ * Device Tree Source for IBM Ebony
+ *
+ * Copyright (c) 2006, 2007 IBM Corp.
+ * Josh Boyer <jdub@us.ibm.com>, David Gibson <dwg@au1.ibm.com>
+ *
+ * FIXME: Draft only!
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ * To build:
+ *   dtc -I dts -O asm -o ebony.S -b 0 -V 16 ebony.dts
+ *   dtc -I dts -O dtb -o ebony.dtb -b 0 -V 16 ebony.dts
+ */
+
+/ {
+	#address-cells = <2>;
+	#size-cells = <1>;
+	model = "Ebony";
+	compatible = "Ebony";
+	dcr-parent = <&/cpus/PowerPC,440GP>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		PowerPC,440GP {
+			device_type = "cpu";
+			reg = <0>;
+			clock-frequency = <5F5E100>; /* 100MHz FIXME: poke in zImage */
+			timebase-frequency = <5F5E100>; /* 100MHz FIXME: wrong, poke in zImage */
+			i-cache-line-size = <32>;
+			d-cache-line-size = <32>;
+			i-cache-size = <0>;
+			d-cache-size = <0>;
+			dcr-controller;
+			dcr-access-method = "native";
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0 00000000 08000000>; /* Set by bootwrapper */
+	};
+
+	UIC0: interrupt-controller { /* UIC0 */
+		device_type = "interrupt-controller";
+		compatible = "ibm,uic440gp", "ibm,uic";
+		interrupt-controller;
+		cell-index = <0>;
+		dcr-reg = <0c0 009>;
+		#address-cells = <0>;
+		#size-cells = <0>;
+		#interrupt-cells = <2>;
+
+		UIC1: interrupt-controller@1 { /* UIC1 */
+			device_type = "interrupt-controller";
+			compatible = "ibm,uic440gp", "ibm,uic";
+			interrupt-controller;
+			cell-index = <1>;
+			dcr-reg = <0d0 009>;
+			#address-cells = <0>;
+			#size-cells = <0>;
+			#interrupt-cells = <2>;
+			interrupts = <1e 4 1f 4>; /* cascade */
+		};
+	};
+
+	plb {
+		device_type = "soc";
+		compatible = "ibm,plb-440gp", "ibm,plb4";
+		ranges;
+
+		POB0: opb@0 {
+			device_type = "soc";
+			compatible = "ibm,opb-440gp", "ibm,opb";
+			ranges;
+			dcr-reg = <090 00b>;
+			interrupt-parent = <&UIC1>;
+			interrupts = <7 4>;
+			clock-frequency = <3ef1480>; // FIXME: 66MHz
+
+			UART0: serial@140000200 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <1 40000200 8>;
+				virtual-reg = <e0000200>;
+				clock-frequency = <A8C000>;
+				current-speed = <2580>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <0 4>;
+			};
+
+			UART1: serial@140000300 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <1 40000300 8>;
+				virtual-reg = <e0000300>;
+				clock-frequency = <A8C000>;
+				current-speed = <2580>; /* FIXME */
+				interrupt-parent = <&UIC0>;
+				interrupts = <1 4>;
+			};
+
+			IIC0: i2c@140000400 {
+				/* FIXME */
+				device_type = "i2c";
+				compatible = "ibm,iic-440gp", "ibm,iic";
+				reg = <1 40000400 14>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <2 4>;
+			};
+			IIC1: i2c@140000500 {
+				/* FIXME */
+				device_type = "i2c";
+				compatible = "ibm,iic-440gp", "ibm,iic";
+				reg = <1 40000500 14>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <3 4>;
+			};
+
+			GPIO0: gpio@140000700 {
+				/* FIXME */
+				device_type = "gpio";
+				compatible = "ibm,gpio-440gp";
+				reg = <1 40000700 20>;
+			};
+
+			ZMII0: emac-zmii@140000780 {
+				device_type = "emac-zmii";
+				compatible = "ibm,zmii-440gp", "ibm,zmii";
+				reg = <1 40000780 c>;
+			};
+
+			EMAC0: ethernet@140000800 {
+				device_type = "network";
+				compatible = "ibm,emac-440gp", "ibm,emac";
+				interrupt-parent = <&UIC1>;
+				interrupts = <1c 4 1d 4>;
+				reg = <1 40000800 70>;
+				local-mac-address = [0004ace31b1e]; // FIXME
+				mal-device = <&MAL0>;
+				mal-tx-channel = <0 1>;
+				mal-rx-channel = <0>;
+				cell-index = <0>;
+				max-frame-size = <5dc>;
+				rx-fifo-size = <1000>;
+				tx-fifo-size = <800>;
+				phy-mode = "rmii";
+				phy-map = <00000001>;
+				zmii-device = <&ZMII0>;
+				zmii-channel = <0>;
+			};
+			EMAC1: ethernet@140000900 {
+				device_type = "network";
+				compatible = "ibm,emac-440gp", "ibm,emac";
+				interrupt-parent = <&UIC1>;
+				interrupts = <1e 4 1f 4>;
+				reg = <1 40000900 70>;
+				local-mac-address = [0004ace31b1f]; // FIXME
+				mal-device = <&MAL0>;
+				mal-tx-channel = <2 3>;
+				mal-rx-channel = <1>;
+				cell-index = <1>;
+				max-frame-size = <5dc>;
+				rx-fifo-size = <1000>;
+				tx-fifo-size = <800>;
+				phy-mode = "rmii";
+				phy-map = <00000001>;
+				zmii-device = <&ZMII0>;
+				zmii-channel = <1>;
+			};
+
+
+			GPT0: gpt@140000a00 {
+				/* FIXME */
+				reg = <1 40000a00 d4>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <12 4 13 4 14 4 15 4 16 4>;
+			};
+
+		};
+
+		PCIX0: pci@1234 {
+			device_type = "pci";
+			/* FIXME */
+			reg = <2 0ec00000 8
+			       2 0ec80000 f0
+			       2 0ec80100 fc>;
+		};
+
+		MAL0: mcmal {
+			/* FIXME */
+			device_type = "mcmal-dma";
+			compatible = "ibm,mcmal-440gp", "ibm,mcmal";
+			dcr-reg = <180 62>;
+			num-tx-chans = <4>;
+			num-rx-chans = <4>;
+			interrupt-parent = <&MAL0>;
+			interrupts = <0 1 2 3 4>;
+			#interrupt-cells = <1>;
+			#address-cells = <0>;
+			#size-cells = <0>;
+			interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+					 /*RXEOB*/ 1 &UIC0 b 4
+					 /*SERR*/  2 &UIC1 0 4
+					 /*TXDE*/  3 &UIC1 1 4
+					 /*RXDE*/  4 &UIC1 2 4>;
+			interrupt-map-mask = <ffffffff>;
+		};
+	};
+
+	chosen {
+		linux,stdout-path = "/plb/opb@0/serial@140000200";
+		linux,initrd-start = <0>; /* FIXME */
+		linux,initrd-end = <0>;
+		interrupt-controller = <&UIC0>;
+	};
+};
+

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		PowerPC,440GP {

PowerPC,440GP@0

> +			clock-frequency = <5F5E100>; /* 100MHz FIXME: poke in zImage */
> +			timebase-frequency = <5F5E100>; /* 100MHz FIXME: wrong, poke in 
> zImage */

Can't you use decimal for these?

> +	UIC0: interrupt-controller { /* UIC0 */

> +		#address-cells = <0>;
> +		#size-cells = <0>;

#address-cells = 0 never makes sense.

> +	plb {
> +		device_type = "soc";
> +		compatible = "ibm,plb-440gp", "ibm,plb4";
> +		ranges;

You need a #address-cells, #size-cells here.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[David Gibson]

On Tue, Feb 13, 2007 at 09:08:52PM +0100, Segher Boessenkool wrote:
> > +	cpus {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		PowerPC,440GP {
> 
> PowerPC,440GP@0

Hmm.. yeah, I'll fix that.

> > +			clock-frequency = <5F5E100>; /* 100MHz FIXME: poke in zImage */
> > +			timebase-frequency = <5F5E100>; /* 100MHz FIXME: wrong, poke in 
> > zImage */
> 
> Can't you use decimal for these?

dtc doesn't support decimal cells at present.  Suggest a good syntax
for doing it, and I'll add the feature.

> > +	UIC0: interrupt-controller { /* UIC0 */
> 
> > +		#address-cells = <0>;
> > +		#size-cells = <0>;
> 
> #address-cells = 0 never makes sense.

Why not?  Children of this node have and need no reg property, and no
meaningful address.  Sounds like #address-cells = 0 to me.

> > +	plb {
> > +		device_type = "soc";
> > +		compatible = "ibm,plb-440gp", "ibm,plb4";
> > +		ranges;
> 
> You need a #address-cells, #size-cells here.

Why?  The values inherited from the root node are perfectly ok here.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 15/16] Add device tree for Ebony

[Benjamin Herrenschmidt]

> > > +	UIC0: interrupt-controller { /* UIC0 */
> > 
> > > +		#address-cells = <0>;
> > > +		#size-cells = <0>;
> > 
> > #address-cells = 0 never makes sense.
> 
> Why not?  Children of this node have and need no reg property, and no
> meaningful address.  Sounds like #address-cells = 0 to me.

In fact, not only it does make perfect sense but it's also routinely
used for ... interrupt controllers :-) That's among others why the
interrupt map entries "second" part usually doesn't contain the address
cells.

> > > +	plb {
> > > +		device_type = "soc";
> > > +		compatible = "ibm,plb-440gp", "ibm,plb4";
> > > +		ranges;
> > 
> > You need a #address-cells, #size-cells here.
> 
> Why?  The values inherited from the root node are perfectly ok here.

Inheriting values is out of spec. The kernel somewhat does it but that's
a bad habit, we should always have them explicit.

Ben.

Re: [PATCH 15/16] Add device tree for Ebony

[David Gibson]

On Wed, Feb 14, 2007 at 12:51:06PM +1100, Benjamin Herrenschmidt wrote:
> 
> > > > +	UIC0: interrupt-controller { /* UIC0 */
> > > 
> > > > +		#address-cells = <0>;
> > > > +		#size-cells = <0>;
> > > 
> > > #address-cells = 0 never makes sense.
> > 
> > Why not?  Children of this node have and need no reg property, and no
> > meaningful address.  Sounds like #address-cells = 0 to me.
> 
> In fact, not only it does make perfect sense but it's also routinely
> used for ... interrupt controllers :-) That's among others why the
> interrupt map entries "second" part usually doesn't contain the address
> cells.

Oh, btw, I take it you didn't think my method of placing the secondary
UICs under the node for UIC0 was insane.

> > > > +	plb {
> > > > +		device_type = "soc";
> > > > +		compatible = "ibm,plb-440gp", "ibm,plb4";
> > > > +		ranges;
> > > 
> > > You need a #address-cells, #size-cells here.
> > 
> > Why?  The values inherited from the root node are perfectly ok here.
> 
> Inheriting values is out of spec. The kernel somewhat does it but that's
> a bad habit, we should always have them explicit.

Ah, ok.  Values added.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

> Oh, btw, I take it you didn't think my method of placing the secondary
> UICs under the node for UIC0 was insane.

You have to put it somewhere.  I would put them
as siblings to the primary UIC since they aren't
really children but really on an equal footing.

Your way works too though.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[David Gibson]

On Wed, Feb 14, 2007 at 06:54:06PM +0100, Segher Boessenkool wrote:
> > Oh, btw, I take it you didn't think my method of placing the secondary
> > UICs under the node for UIC0 was insane.
> 
> You have to put it somewhere.  I would put them
> as siblings to the primary UIC since they aren't
> really children but really on an equal footing.

Well, what does "really children" mean.  The UICs exist on no MMIO
bus, they're DCR controlled.  Their primary connection to the system,
therefore, *is* the interrupt lines.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> You have to put it somewhere.  I would put them
>> as siblings to the primary UIC since they aren't
>> really children but really on an equal footing.
>
> Well, what does "really children" mean.  The UICs exist on no MMIO
> bus, they're DCR controlled.

Well exactly, thanks for making my point :-)


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>>>> +	UIC0: interrupt-controller { /* UIC0 */
>>>
>>>> +		#address-cells = <0>;
>>>> +		#size-cells = <0>;
>>>
>>> #address-cells = 0 never makes sense.
>>
>> Why not?  Children of this node have and need no reg property, and no
>> meaningful address.  Sounds like #address-cells = 0 to me.
>
> In fact, not only it does make perfect sense but it's also routinely
> used for ... interrupt controllers :-) That's among others why the
> interrupt map entries "second" part usually doesn't contain the address
> cells.

Can you please explain this in detail?  Children of such
a node (a node with #a = 0) have no "reg" property --
maybe something in the interrupt tree stuff still needs
a #a in the interrupt controller node, but I fail to
see what right now.

>>> You need a #address-cells, #size-cells here.
>>
>> Why?  The values inherited from the root node are perfectly ok here.
>
> Inheriting values is out of spec.

It's not just out of spec but directly contradicting it.

> The kernel somewhat does it but that's
> a bad habit, we should always have them explicit.

The kernel should really only do it on firmwares that
need this quirk.  Alternatively, some early fix up
pass could add the properties on such a firmware.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>>> +			clock-frequency = <5F5E100>; /* 100MHz FIXME: poke in zImage */
>>> +			timebase-frequency = <5F5E100>; /* 100MHz FIXME: wrong, poke in
>>> zImage */
>>
>> Can't you use decimal for these?
>
> dtc doesn't support decimal cells at present.  Suggest a good syntax
> for doing it, and I'll add the feature.

d# 100000000    like is used in "real" OF?

>>> +	UIC0: interrupt-controller { /* UIC0 */
>>
>>> +		#address-cells = <0>;
>>> +		#size-cells = <0>;
>>
>> #address-cells = 0 never makes sense.
>
> Why not?  Children of this node have and need no reg property, and no
> meaningful address.  Sounds like #address-cells = 0 to me.

There cannot *exist* any children of the node.  Unless
your hardware is really weird.  I guess it is :-)

In such a case, you just don't put a "reg" property in
the kid nodes.

>>> +	plb {
>>> +		device_type = "soc";
>>> +		compatible = "ibm,plb-440gp", "ibm,plb4";
>>> +		ranges;
>>
>> You need a #address-cells, #size-cells here.
>
> Why?  The values inherited from the root node are perfectly ok here.

Values aren't inherited.  Missing #address-cells, #size-cells
properties mean 2 and 1 respectively.  And it's good practice
to always fill them in explicitly.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Benjamin Herrenschmidt]

> There cannot *exist* any children of the node.  Unless
> your hardware is really weird.  I guess it is :-)
> 
> In such a case, you just don't put a "reg" property in
> the kid nodes.

No. The #address-cells in the interrupt controller is necessary to
define the size of the unit address part of the unit interrupt specifier
of interrupt children. Re-read your spec :-)

Having it set to 0 provides the necessary definition so that the "right
hand" members of an interrupt map don't need a unit address in their
unit interrupt specifier.

Ben.

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> There cannot *exist* any children of the node.  Unless
>> your hardware is really weird.  I guess it is :-)
>>
>> In such a case, you just don't put a "reg" property in
>> the kid nodes.
>
> No. The #address-cells in the interrupt controller is necessary to
> define the size of the unit address part of the unit interrupt 
> specifier
> of interrupt children. Re-read your spec :-)

Like I said (perhaps elsewhere in this thread), there
might be something in the interrupt mapping spec yes.

But I don't see what...  read on...

> Having it set to 0 provides the necessary definition so that the "right
> hand" members of an interrupt map don't need a unit address in their
> unit interrupt specifier.

And a missing #address-cells property means 0 for the
purpose of interrupt mapping.  Here, have some quotes
from the spec:


> For nodes that represent devices, the number of cells to represent a 
> unit interrupt specifier  is the  sum of the "#address-cells"  and 
> "#interrupt-cells"  properties; for nodes that do  not represent 
> devices, there is no relevant "#address-cells"  value, so that the 
> number of cells  is solely determined by the "#interrupt-cells" value. 
>  The latter case exists due to the nature of representing interrupt 
> mapping outside the context of the normal device tree.


> Note that the "open-pic" node does not have a "#address-cells" 
> property, so that  the number of cells for the parent unit interrupt 
> specifiers is 2 (which is the value of its "#interrupt-cells" 
> property).


> if present( "#address-cells", parent-node )
> 	#cells = valueof( "#address-cells", parent-node )
> else #cells = 0   then



Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Benjamin Herrenschmidt]

> > Having it set to 0 provides the necessary definition so that the "right
> > hand" members of an interrupt map don't need a unit address in their
> > unit interrupt specifier.
> 
> And a missing #address-cells property means 0 for the
> purpose of interrupt mapping.  Here, have some quotes
> from the spec:
> 
> 
> > For nodes that represent devices, the number of cells to represent a 
> > unit interrupt specifier  is the  sum of the "#address-cells"  and 
> > "#interrupt-cells"  properties; for nodes that do  not represent 
> > devices, there is no relevant "#address-cells"  value, so that the 
> > number of cells  is solely determined by the "#interrupt-cells" value. 
> >  The latter case exists due to the nature of representing interrupt 
> > mapping outside the context of the normal device tree.
> 
> 
> > Note that the "open-pic" node does not have a "#address-cells" 
> > property, so that  the number of cells for the parent unit interrupt 
> > specifiers is 2 (which is the value of its "#interrupt-cells" 
> > property).
> 
> 
> > if present( "#address-cells", parent-node )
> > 	#cells = valueof( "#address-cells", parent-node )
> > else #cells = 0   then

Yes, "missing" is equivalent to 0, but the common practice has always
been to specify it explicitely. Check existing Apple and IBM
device-trees for example.

Ben.

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>>> Note that the "open-pic" node does not have a "#address-cells"
>>> property, so that  the number of cells for the parent unit interrupt
>>> specifiers is 2 (which is the value of its "#interrupt-cells"
>>> property).

> Yes, "missing" is equivalent to 0,

...and the reason for that is that nodes without physical
children should not _have_ a "#address-cells" property.

> but the common practice has always
> been to specify it explicitely. Check existing Apple and IBM
> device-trees for example.

You do realise how many other borderline (or outright
wrong) things are done in those trees, right?

It doesn't really hurt to have a "#a = 0" prop, but it's
better to just not have a #a prop if you shouldn't have one.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Benjamin Herrenschmidt]

On Thu, 2007-02-15 at 02:00 +0100, Segher Boessenkool wrote:
> >>> Note that the "open-pic" node does not have a "#address-cells"
> >>> property, so that  the number of cells for the parent unit interrupt
> >>> specifiers is 2 (which is the value of its "#interrupt-cells"
> >>> property).
> 
> > Yes, "missing" is equivalent to 0,
> 
> ...and the reason for that is that nodes without physical
> children should not _have_ a "#address-cells" property.
> 
> > but the common practice has always
> > been to specify it explicitely. Check existing Apple and IBM
> > device-trees for example.
> 
> You do realise how many other borderline (or outright
> wrong) things are done in those trees, right?
> 
> It doesn't really hurt to have a "#a = 0" prop, but it's
> better to just not have a #a prop if you shouldn't have one.

Let's have one for now. I think that's how I documented it and it works
fine while I'm not sure the kernel code will cope with not having it (it
may ... or not).

There are various issues with the OF bindings, especially the imap one
(and some pretty bad bugs in it) and that's one of the reason I prefer
not leaving anything to be "implicit" like this case. It want explicit
mention of #address-cells/#size-cells/#interrupt-cells at all levels
where they might enter the parser.

Ben.

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> It doesn't really hurt to have a "#a = 0" prop, but it's
>> better to just not have a #a prop if you shouldn't have one.
>
> Let's have one for now. I think that's how I documented it and it works
> fine while I'm not sure the kernel code will cope with not having it 
> (it
> may ... or not).

It *used* to work some months ago, at least.

> There are various issues with the OF bindings, especially the imap one
> (and some pretty bad bugs in it)

You keep saying this but I can't find any (except in the
examples, there are some really obvious bugs there -- but
examples aren't part of the binding /per se/).  Can you
please tell me what these bugs are?

> and that's one of the reason I prefer
> not leaving anything to be "implicit" like this case.

It is not implicit; it is an exception.  It really is
wrong to have the #address-cells property in a node
like this (though pretty much harmless in practice).

> It want explicit
> mention of #address-cells/#size-cells/#interrupt-cells at all levels
> where they might enter the parser.

But they *cannot* be used by the parser (for memory
regions) here; and the parser for interrupt mappings
better handle this case correctly (and like I said,
I believe it does, at least in some cases ;-) ).

What you're really saying is "my code might handle
edge cases incorrectly, so please enter incorrect
input to avoid those cases".


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[David Gibson]

On Wed, Feb 14, 2007 at 06:48:02PM +0100, Segher Boessenkool wrote:
> >>> +			clock-frequency = <5F5E100>; /* 100MHz FIXME: poke in zImage */
> >>> +			timebase-frequency = <5F5E100>; /* 100MHz FIXME: wrong, poke in
> >>> zImage */
> >>
> >> Can't you use decimal for these?
> >
> > dtc doesn't support decimal cells at present.  Suggest a good syntax
> > for doing it, and I'll add the feature.
> 
> d# 100000000    like is used in "real" OF?

Sorry, I don't entirely follow.  How does this sit in the context of a
dtc property definition? foo = <d# 100>;?  foo = d# 100 200;?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>>>> Can't you use decimal for these?
>>>
>>> dtc doesn't support decimal cells at present.  Suggest a good syntax
>>> for doing it, and I'll add the feature.
>>
>> d# 100000000    like is used in "real" OF?
>
> Sorry, I don't entirely follow.  How does this sit in the context of a
> dtc property definition? foo = <d# 100>;?  foo = d# 100 200;?

The first option.  Anywhere a number can be used, "d# xxx"
would mean decimal.

When you would say <d# 1234  5678>, 1234 is decimal and
5678 is hexadecimal.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Jon Loeliger]

So, like, the other day Segher Boessenkool mumbled:
> The first option.  Anywhere a number can be used, "d# xxx"
> would mean decimal.
> 
> When you would say <d# 1234  5678>, 1234 is decimal and
> 5678 is hexadecimal.

Where do the tokens end?  Is "d#1234" valid and equal to "d# 1234"?
Or is "d#" an independent token?  And are there other bases to
this model?  Like, maybe, "b#", "o#" and "h#" as well?

jdl

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> The first option.  Anywhere a number can be used, "d# xxx"
>> would mean decimal.
>>
>> When you would say <d# 1234  5678>, 1234 is decimal and
>> 5678 is hexadecimal.
>
> Where do the tokens end?  Is "d#1234" valid and equal to "d# 1234"?
> Or is "d#" an independent token?

In OF, there has to be whitespace inbetween.

> And are there other bases to
> this model?  Like, maybe, "b#", "o#" and "h#" as well?

o# d# h# are standard defined; b# exists on many implementations.

Neither b# nor o# is frequently used but there's no harm in
including them I suppose.


Segher

RE: [PATCH 15/16] Add device tree for Ebony

[Yoder Stuart-B08248]

=20

> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Segher Boessenkool
> Sent: Thursday, February 15, 2007 8:57 AM
> To: Jon Loeliger
> Cc: linuxppc-dev@ozlabs.org; David Gibson
> Subject: Re: [PATCH 15/16] Add device tree for Ebony=20
>=20
> >> The first option.  Anywhere a number can be used, "d# xxx"
> >> would mean decimal.
> >>
> >> When you would say <d# 1234  5678>, 1234 is decimal and
> >> 5678 is hexadecimal.
> >
> > Where do the tokens end?  Is "d#1234" valid and equal to "d# 1234"?
> > Or is "d#" an independent token?
>=20
> In OF, there has to be whitespace inbetween.
>=20
> > And are there other bases to
> > this model?  Like, maybe, "b#", "o#" and "h#" as well?
>=20
> o# d# h# are standard defined; b# exists on many implementations.

1275 specifies whitespace inbetween, but isn't this due to=20
the way they are describing things for the forth / stack-based
operations?

I would prefer in the DTS files to have no whitespace in=20
between--  <d#1234 #h5678> seems much more readable
than <d# 1234 #h 5678>.

Or even better-- just use standard C notation
    <1234 0x5678>

That is very readable.  Why bring unnecessary complexity into
this?

Stuart

Re: [PATCH 15/16] Add device tree for Ebony

[Scott Wood]

Yoder Stuart-B08248 wrote:
> 1275 specifies whitespace inbetween, but isn't this due to 
> the way they are describing things for the forth / stack-based
> operations?
> 
> I would prefer in the DTS files to have no whitespace in 
> between--  <d#1234 #h5678> seems much more readable
> than <d# 1234 #h 5678>.
> 
> Or even better-- just use standard C notation
>     <1234 0x5678>
> 
> That is very readable.  Why bring unnecessary complexity into
> this?

Decimal-by-default C notation would break compatibility (undetectably, 
in the case of hex constants that don't happen to use digits above 9) 
with current DTS files which are hex-by-default -- and besides, most of 
the values are going to be hex.

I agree that allowing the space to be omitted would be a good thing.

-Scott

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

> 1275 specifies whitespace inbetween, but isn't this due to
> the way they are describing things for the forth / stack-based
> operations?

Sure, since for true OF d# etc. are Forth words and thus
are whitespace delimited.

> I would prefer in the DTS files to have no whitespace in
> between--  <d#1234 #h5678> seems much more readable
> than <d# 1234 #h 5678>.

[h# not #h] Sure, make it optional, that should work just fine.

> Or even better-- just use standard C notation
>     <1234 0x5678>

Right now no prefix means hexadecimal.  So you need a prefix
that means decimal, and C has none.

> That is very readable.  Why bring unnecessary complexity into
> this?

It's all historical accident I suppose.  Since the DTS
format tries to look like C it should have used 0x all
along.  It's not too late too change btw, the DTS is not
the actual interface, the binary blob that is passed
around doesn't care what number base you used in the
source code.


Segher

RE: [PATCH 15/16] Add device tree for Ebony

[Yoder Stuart-B08248]

I realize the dts is preliminary, but saw some stuff and=20
thought I would comment.

> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of David Gibson

[snip]

> +	UIC0: interrupt-controller { /* UIC0 */
> +		device_type =3D "interrupt-controller";
> +		compatible =3D "ibm,uic440gp", "ibm,uic";
> +		interrupt-controller;
> +		cell-index =3D <0>;
> +		dcr-reg =3D <0c0 009>;
> +		#address-cells =3D <0>;
> +		#size-cells =3D <0>;
> +		#interrupt-cells =3D <2>;
> +
> +		UIC1: interrupt-controller@1 { /* UIC1 */
> +			device_type =3D "interrupt-controller";
> +			compatible =3D "ibm,uic440gp", "ibm,uic";
> +			interrupt-controller;
> +			cell-index =3D <1>;
> +			dcr-reg =3D <0d0 009>;
> +			#address-cells =3D <0>;
> +			#size-cells =3D <0>;
> +			#interrupt-cells =3D <2>;
> +			interrupts =3D <1e 4 1f 4>; /* cascade */
> +		};
> +	};

Did you mean to have UIC1 nested under UIC0 or should
they be at the same level?

> +	plb {
> +		device_type =3D "soc";
> +		compatible =3D "ibm,plb-440gp", "ibm,plb4";
> +		ranges;
> +
> +		POB0: opb@0 {
> +			device_type =3D "soc";
> +			compatible =3D "ibm,opb-440gp", "ibm,opb";
> +			ranges;
> +			dcr-reg =3D <090 00b>;
> +			interrupt-parent =3D <&UIC1>;
> +			interrupts =3D <7 4>;
> +			clock-frequency =3D <3ef1480>; // FIXME: 66MHz

Hmm.  There are two "soc" devices here, one nested under the
first??

I'm assuming these are two levels of busses the opb bus is attached
to the plb bus.  Is the "soc" device_type the right way to=20
do this?

Stuart

RE: [PATCH 15/16] Add device tree for Ebony

[Josh Boyer]

On Wed, 2007-02-14 at 09:14 -0700, Yoder Stuart-B08248 wrote:
> I realize the dts is preliminary, but saw some stuff and 
> thought I would comment.
> 
> > -----Original Message-----
> > From: linuxppc-dev-bounces+b08248=freescale.com@ozlabs.org 
> > [mailto:linuxppc-dev-bounces+b08248=freescale.com@ozlabs.org] 
> > On Behalf Of David Gibson
> 
> [snip]
> 
> > +	UIC0: interrupt-controller { /* UIC0 */
> > +		device_type = "interrupt-controller";
> > +		compatible = "ibm,uic440gp", "ibm,uic";
> > +		interrupt-controller;
> > +		cell-index = <0>;
> > +		dcr-reg = <0c0 009>;
> > +		#address-cells = <0>;
> > +		#size-cells = <0>;
> > +		#interrupt-cells = <2>;
> > +
> > +		UIC1: interrupt-controller@1 { /* UIC1 */
> > +			device_type = "interrupt-controller";
> > +			compatible = "ibm,uic440gp", "ibm,uic";
> > +			interrupt-controller;
> > +			cell-index = <1>;
> > +			dcr-reg = <0d0 009>;
> > +			#address-cells = <0>;
> > +			#size-cells = <0>;
> > +			#interrupt-cells = <2>;
> > +			interrupts = <1e 4 1f 4>; /* cascade */
> > +		};
> > +	};
> 
> Did you mean to have UIC1 nested under UIC0 or should
> they be at the same level?

No, they are cascaded in hardware.  I think having UIC1 under UCI0 is a
correct representation.

> 
> > +	plb {
> > +		device_type = "soc";
> > +		compatible = "ibm,plb-440gp", "ibm,plb4";
> > +		ranges;
> > +
> > +		POB0: opb@0 {
> > +			device_type = "soc";
> > +			compatible = "ibm,opb-440gp", "ibm,opb";
> > +			ranges;
> > +			dcr-reg = <090 00b>;
> > +			interrupt-parent = <&UIC1>;
> > +			interrupts = <7 4>;
> > +			clock-frequency = <3ef1480>; // FIXME: 66MHz
> 
> Hmm.  There are two "soc" devices here, one nested under the
> first??
> 
> I'm assuming these are two levels of busses the opb bus is attached
> to the plb bus.  Is the "soc" device_type the right way to 
> do this?

Right, OPB hangs off of PLB in this case.  I dunno if "soc" is the right
device type for them though.

josh

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> Did you mean to have UIC1 nested under UIC0 or should
>> they be at the same level?
>
> No, they are cascaded in hardware.  I think having UIC1 under UCI0 is a
> correct representation.

Only the interrupt routing is cascaded AFAICS, and
there is a separate interrupt tree to express that.

>> Hmm.  There are two "soc" devices here, one nested under the
>> first??
>>
>> I'm assuming these are two levels of busses the opb bus is attached
>> to the plb bus.  Is the "soc" device_type the right way to
>> do this?
>
> Right, OPB hangs off of PLB in this case.  I dunno if "soc" is the 
> right
> device type for them though.

I would use device_type "plb" (or "plb4") and "opb" I think.
Similar to how PCI and ISA etc. busses are represented.


Segher

RE: [PATCH 15/16] Add device tree for Ebony

[Yoder Stuart-B08248]

=20
> >> Hmm.  There are two "soc" devices here, one nested under the
> >> first??
> >>
> >> I'm assuming these are two levels of busses the opb bus is attached
> >> to the plb bus.  Is the "soc" device_type the right way to
> >> do this?
> >
> > Right, OPB hangs off of PLB in this case.  I dunno if "soc" is the=20
> > right
> > device type for them though.
>=20
> I would use device_type "plb" (or "plb4") and "opb" I think.
> Similar to how PCI and ISA etc. busses are represented.

I think we should avoid making up new device_types unlesss it
really is necessary.

Is it really necessary to distinguish between devices on
the PLB or OPB?

As I undestand it the "soc" device type is a logical container
for a group of devices in an SOC, not necessarily a group
of devices on the same bus.  Could we simply list all those
devices under an "soc" node at the same level.

If for some reason the bus hierarchy distinction _is_ required,
my suggestion would be to create new generic device type for
representing an internal bus.   The "device_type" is supposed
to be somewhat general-- "network", "serial", etc.

We could create something like "soc-bus" or "internal-bus" with
a compatible field that identifies the type of bus.

The general philosophy is a general device_type prooperty and
a specific compatible property.

Stuart Yoder

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> I would use device_type "plb" (or "plb4") and "opb" I think.
>> Similar to how PCI and ISA etc. busses are represented.
>
> I think we should avoid making up new device_types unlesss it
> really is necessary.

In the case of peripheral busses there is significant
precedence though.  And it makes a lot of sense, too.

> Is it really necessary to distinguish between devices on
> the PLB or OPB?

This isn't about devices on the bus -- it is about the
bus itself.

> As I undestand it the "soc" device type is a logical container
> for a group of devices in an SOC, not necessarily a group
> of devices on the same bus.  Could we simply list all those
> devices under an "soc" node at the same level.

A "soc" node is meant to contain SoC specific stuff like
clock registers or whatnot.  It typically wouldn't have
child nodes.

> If for some reason the bus hierarchy distinction _is_ required,

It doesn't matter if you feel it is required.  You could in
principal list all devices as direct children of the root
node, if you take your argument to the extreme.  The device
tree is meant to reflect the physical hierarchy of the
devices in the system -- so it should show the PLB etc.
busses.  Maybe some day in the future the kernel can actually
make good use of the extra knowledge -- reconfigure something
about the PLB bus for example, who knows.  Also remember that
the device tree is *not* just for Linux, any argument that
says "Linux doesn't need this" is irrelevant.  And, again,
maybe Linux _could_ make good use of it.

> my suggestion would be to create new generic device type for
> representing an internal bus.   The "device_type" is supposed
> to be somewhat general-- "network", "serial", etc.

The device_type represents the programming model of the
device (programming model for OF).  Each type of bus has
its own programming model.  Your suggestion makes sense
for bus bridges that are 100% transparent -- same address
domain on both sides, completely identical ordering rules,
no configuration whatsoever.  I've never seen such a bus.

> The general philosophy is a general device_type prooperty and
> a specific compatible property.

For devices yes, but these aren't (endpoint) devices.


Segher

RE: [PATCH 15/16] Add device tree for Ebony

[Yoder Stuart-B08248]

=20

> -----Original Message-----
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]=20
> Sent: Wednesday, February 14, 2007 3:12 PM
[snip]
> > As I undestand it the "soc" device type is a logical container
> > for a group of devices in an SOC, not necessarily a group
> > of devices on the same bus.  Could we simply list all those
> > devices under an "soc" node at the same level.
>=20
> A "soc" node is meant to contain SoC specific stuff like
> clock registers or whatnot.  It typically wouldn't have
> child nodes.

That's not what booting_without_of.txt says.  It says:

    The SOC node may contain child nodes for each SOC
    device that the  platform uses.

All the dts files in arch/powerpc/boot/dts I've looked at have
an soc node with a whole bunch of devices under it.

The current practice seems to be that an "soc" node contains
all the on chip devices (regardless of the physical bus internal
to the soc).

> > If for some reason the bus hierarchy distinction _is_ required,
>=20
> It doesn't matter if you feel it is required.  You could in
> principal list all devices as direct children of the root
> node, if you take your argument to the extreme.  The device
> tree is meant to reflect the physical hierarchy of the
> devices in the system -- so it should show the PLB etc.
> busses.  Maybe some day in the future the kernel can actually
> make good use of the extra knowledge -- reconfigure something
> about the PLB bus for example, who knows.  Also remember that
> the device tree is *not* just for Linux, any argument that
> says "Linux doesn't need this" is irrelevant.  And, again,
> maybe Linux _could_ make good use of it.
>=20
> > my suggestion would be to create new generic device type for
> > representing an internal bus.   The "device_type" is supposed
> > to be somewhat general-- "network", "serial", etc.
>=20
> The device_type represents the programming model of the
> device (programming model for OF).

The device_type is typically things like "network" and "serial"
which don't specify the programming model.   The compatible=20
property is used in driver selection.=20

> Each type of bus has
> its own programming model.  Your suggestion makes sense
> for bus bridges that are 100% transparent -- same address
> domain on both sides, completely identical ordering rules,
> no configuration whatsoever.  I've never seen such a bus.

If the busses have different address domains and specific=20
configuration then I agree, they need their own unique device_type.

Do the ipb and opb busses have their own device driver similar to
PCI?

Stuart

RE: [PATCH 15/16] Add device tree for Ebony

[Benjamin Herrenschmidt]

> der an "soc" node at the same level.
> > 
> > A "soc" node is meant to contain SoC specific stuff like
> > clock registers or whatnot.  It typically wouldn't have
> > child nodes.
> 
> That's not what booting_without_of.txt says.  It says:
> 
>     The SOC node may contain child nodes for each SOC
>     device that the  platform uses.
> 
> All the dts files in arch/powerpc/boot/dts I've looked at have
> an soc node with a whole bunch of devices under it.

Wel, that was written by FSL not long ago :-)

> The current practice seems to be that an "soc" node contains
> all the on chip devices (regardless of the physical bus internal
> to the soc).

That's the current FSL practice yes. As I said, I'm not too fan of it. I
prefer a more precise representation of the internal bus layout.

> The device_type is typically things like "network" and "serial"
> which don't specify the programming model.   The compatible 
> property is used in driver selection. 

The device type specifies the programming model of the node for OF, that
is the set of words the driver will provide to OF. So that's something
we don't necessarily care much about for non-OF implementation but still
we should avoid going too far from that model either (after all,
somebody can very well want to use a real OF on a board with a SoC).

The device type is also used by the kernel in some areas. For example,
the spec specifies that PCI host controllers and P2P bridges have a
device-type of "pci" and the kernel relies heavily on that. Same for
ISA. It thus makes sense to continue that practice with other bus types.

Ben.

Re: [PATCH 15/16] Add device tree for Ebony

[Scott Wood]

Benjamin Herrenschmidt wrote:
>>The current practice seems to be that an "soc" node contains
>>all the on chip devices (regardless of the physical bus internal
>>to the soc).
> 
> 
> That's the current FSL practice yes. As I said, I'm not too fan of it. I
> prefer a more precise representation of the internal bus layout.

I think it makes sense at least for the FSL SoCs, in that from an 
addressing perspective it is like a bus -- the entire block of devices 
can be relocated by writing to one IMMRBAR register, and the only 
hardcoded address is the offset into that block.

Putting the devices at the root level would make it harder to implement 
a template dts fragment for a given SoC that can be included in a board 
dts, where different boards may want to put the IMMR in different 
places.  It could be done with macros and addition, but it'd be simpler 
to be able to just update reg and ranges in the soc node.

-Scott

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> That's the current FSL practice yes. As I said, I'm not too fan of 
>> it. I
>> prefer a more precise representation of the internal bus layout.
>
> I think it makes sense at least for the FSL SoCs, in that from an
> addressing perspective it is like a bus -- the entire block of devices
> can be relocated by writing to one IMMRBAR register, and the only
> hardcoded address is the offset into that block.

So it makes a lot of sense to have all those devices
below the "soc" node (in fact, it is almost necessary).

However, that doesn't mean you cannot show the devices
on the internal busses they really sit on (if they do);
you just have to put those busses somewhere under the
"soc" node.  Just model the device tree after reality
and you won't have problems ;-)


Segher

RE: [PATCH 15/16] Add device tree for Ebony

[Yoder Stuart-B08248]

=20

> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]=20
> Sent: Wednesday, February 14, 2007 3:43 PM
> To: Yoder Stuart-B08248
> Cc: Segher Boessenkool; linuxppc-dev@ozlabs.org; David Gibson
> Subject: RE: [PATCH 15/16] Add device tree for Ebony
>=20
> > der an "soc" node at the same level.
> > >=20
> > > A "soc" node is meant to contain SoC specific stuff like
> > > clock registers or whatnot.  It typically wouldn't have
> > > child nodes.
> >=20
> > That's not what booting_without_of.txt says.  It says:
> >=20
> >     The SOC node may contain child nodes for each SOC
> >     device that the  platform uses.
> >=20
> > All the dts files in arch/powerpc/boot/dts I've looked at have
> > an soc node with a whole bunch of devices under it.
>=20
> Wel, that was written by FSL not long ago :-)
>=20
> > The current practice seems to be that an "soc" node contains
> > all the on chip devices (regardless of the physical bus internal
> > to the soc).
>=20
> That's the current FSL practice yes. As I said, I'm not too=20
> fan of it. I
> prefer a more precise representation of the internal bus layout.

Hmm.  I haven't been around here that long and assumed that
the soc node was an approach arrived at after discussion and
debate in the PPC Linux community in general.

> > The device_type is typically things like "network" and "serial"
> > which don't specify the programming model.   The compatible=20
> > property is used in driver selection.=20
>=20
> The device type specifies the programming model of the node=20
> for OF, that
> is the set of words the driver will provide to OF. So that's something
> we don't necessarily care much about for non-OF=20
> implementation but still
> we should avoid going too far from that model either (after all,
> somebody can very well want to use a real OF on a board with a SoC).
>=20
> The device type is also used by the kernel in some areas. For example,
> the spec specifies that PCI host controllers and P2P bridges have a
> device-type of "pci" and the kernel relies heavily on that. Same for
> ISA. It thus makes sense to continue that practice with other=20
> bus types.

Do we need to re-open up the discussion about how to represent
SOCs in the device tree?  Does it matter?  Or, just have different
vendors do it their own way?

Some consistency would be good in my opinion.

Stuart

RE: [PATCH 15/16] Add device tree for Ebony

[Benjamin Herrenschmidt]

> > That's the current FSL practice yes. As I said, I'm not too 
> > fan of it. I
> > prefer a more precise representation of the internal bus layout.
> 
> Hmm.  I haven't been around here that long and assumed that
> the soc node was an approach arrived at after discussion and
> debate in the PPC Linux community in general.

Little discussion, as I said, I don't mind that much neither what
approach FSL uses for their own devices anyway, as long as it's
consistent and works for your needs. For the IBM CoreConnect parts, I'd
like to stick with the device type being "plb", "plb4", "plb5", "opb"
etc... for the various busses.

> Do we need to re-open up the discussion about how to represent
> SOCs in the device tree?  Does it matter?  Or, just have different
> vendors do it their own way?

I don't think it matters in the sense that I don't think we want to
change the current practice of FSL SoCs. It fits your needs well, so
let's stick with it.

> Some consistency would be good in my opinion.

Ben.

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

> The device type specifies the programming model of the node for OF, 
> that
> is the set of words the driver will provide to OF. So that's something
> we don't necessarily care much about for non-OF implementation but 
> still
> we should avoid going too far from that model either (after all,
> somebody can very well want to use a real OF on a board with a SoC).

Exactly.  The "separate device tree" imitates a real OF,
so you will lose much of its value if you start to deviate
from how real OF works.

> The device type is also used by the kernel in some areas. For example,
> the spec specifies that PCI host controllers and P2P bridges have a
> device-type of "pci" and the kernel relies heavily on that. Same for
> ISA. It thus makes sense to continue that practice with other bus 
> types.

Yep, for peripheral busses the kernel's needs are quite the
same as the firmware's needs so it makes sense that both use
device_type.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Paul Mackerras]

Segher Boessenkool writes:

> Exactly.  The "separate device tree" imitates a real OF,
> so you will lose much of its value if you start to deviate
> from how real OF works.

I disagree.  It was never (and isn't now) the intention to put all of
the OF requirements on the device tree supplied on OF-less systems.

In other words, "we should do X because the bindings require it" isn't
of itself an argument for making X a requirement on the device tree.
"We should do X because there are good technical reasons for doing it
that way" is.  "We should do X because if we don't then device trees
from real OF systems won't be compatible" is also a reasonable
argument.

The device tree is required because it is a flexible way to give
useful information to the kernel.  Thus the focus is quite properly on
what is useful (or at least potentially useful) to the Linux kernel,
not on what some binding document says.

Paul.

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> Exactly.  The "separate device tree" imitates a real OF,
>> so you will lose much of its value if you start to deviate
>> from how real OF works.
>
> I disagree.  It was never (and isn't now) the intention to put all of
> the OF requirements on the device tree supplied on OF-less systems.

That's not my point; I'm saying that you shouldn't do the
same (or similar) things in different ways than "real OF"
does.

> In other words, "we should do X because the bindings require it" isn't
> of itself an argument for making X a requirement on the device tree.

It's a pretty strong indicator though; all other things
being equal, you should do what the bindings say.  There
can be good reasons to do differently, but then you better
have those reasons :-)

> "We should do X because there are good technical reasons for doing it
> that way" is.  "We should do X because if we don't then device trees
> from real OF systems won't be compatible" is also a reasonable
> argument.

You're turning the argument around, but hey :-)

> The device tree is required because it is a flexible way to give
> useful information to the kernel.  Thus the focus is quite properly on
> what is useful (or at least potentially useful) to the Linux kernel,
> not on what some binding document says.

Still, if you want to be compatible to "real OF" (and you
do, otherwise you would have chosen a structure that is
more appropriate for this goal), you better *be* compatible
to OF.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Paul Mackerras]

Segher Boessenkool writes:

> Still, if you want to be compatible to "real OF" (and you
> do, otherwise you would have chosen a structure that is
> more appropriate for this goal),

We don't require an OF device tree; what we require is something that
provides a way to express what the kernel needs to know about the
hierarchy, interconnections and characteristics of the devices in the
system.  That it looks strangely familiar to you is just a
coincidence. :)

Paul.

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> Still, if you want to be compatible to "real OF" (and you
>> do, otherwise you would have chosen a structure that is
>> more appropriate for this goal),
>
> We don't require an OF device tree;

When booting on real OF you do.

> what we require is something that
> provides a way to express what the kernel needs to know about the
> hierarchy, interconnections and characteristics of the devices in the
> system.

Sure.  You could have chosen a structure that is closer to the
internal Linux structures.

> That it looks strangely familiar to you is just a
> coincidence. :)

Heh suuuuuuuure :-)


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Paul Mackerras]

Segher Boessenkool writes:

> > We don't require an OF device tree;
> 
> When booting on real OF you do.

No, the kernel requires a flattened tree, which is created by glue
code from the OF device tree.  Currently everything in the OF tree
goes across into the flattened tree, but in future there may not be a
1-1 correspondence.

> > what we require is something that
> > provides a way to express what the kernel needs to know about the
> > hierarchy, interconnections and characteristics of the devices in the
> > system.
> 
> Sure.  You could have chosen a structure that is closer to the
> internal Linux structures.

What internal Linux structures?  In any case it's a mistake to tie
internal and external structures together because it creates future
compatibility headaches.

> > That it looks strangely familiar to you is just a
> > coincidence. :)
> 
> Heh suuuuuuuure :-)

The device tree is basically a generalization of the list of tags +
values that ppc and other architectures use.  The tags are strings
rather than numbers, because that makes sense, and you can group sets
of tags + values that relate to a particular device together, and you
can link devices together in a hierarchical arrangement.

The last thing I want to do is to put unnecessary burdens on embedded
platforms just to comply with OF requirements.  We have the device
tree because it makes sense both for embedded and for desktop/server
machines, not because OF is some sort of holy writ.

Paul.

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>>> We don't require an OF device tree;
>>
>> When booting on real OF you do.
>
> No, the kernel requires a flattened tree, which is created by glue
> code from the OF device tree.

Heh.  And you really think that "glue code" will ever not
be linked into the zImage, and distributed with the kernel
code?

> Currently everything in the OF tree
> goes across into the flattened tree, but in future there may not be a
> 1-1 correspondence.

Which would be a mistake IMNSHO.  Sure you want to do some
fixups on broken things in some trees, but that's all.

Or perhaps you mean you would morph the tree into some
completely different format?  That would be fine, just
make sure it is obvious it is something different.

>> Sure.  You could have chosen a structure that is closer to the
>> internal Linux structures.
>
> What internal Linux structures?

The Linux device abstractions, for example.

> In any case it's a mistake to tie
> internal and external structures together because it creates future
> compatibility headaches.

You don't have to tell _me_ that.

>>> That it looks strangely familiar to you is just a
>>> coincidence. :)
>>
>> Heh suuuuuuuure :-)
>
> The device tree is basically a generalization of the list of tags +
> values that ppc and other architectures use.

Yeah whatever.  It is a *complete* accident that it is
virtually identical to OF.  I believe you.

> The tags are strings
> rather than numbers, because that makes sense, and you can group sets
> of tags + values that relate to a particular device together, and you
> can link devices together in a hierarchical arrangement.

Not just "you can", you *must*.  The way they are connected
has a lot of meaning.  Remove that and everything starts
falling apart.

> The last thing I want to do is to put unnecessary burdens on embedded
> platforms just to comply with OF requirements.

Then you should define a simpler format that hopefully can
handle everything that OF can.  Maybe you can do a better
job if you really think OF is overly complicated.

> We have the device
> tree because it makes sense both for embedded and for desktop/server
> machines, not because OF is some sort of holy writ.

Whatever interface definition you do create, it will be "holy
writ".  Since almost nothing is written down (complete enough
and without major errors and inconsistencies) elsewhere, there
is no other choice right now than to fall back to the OF specs.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>>> As I undestand it the "soc" device type is a logical container
>>> for a group of devices in an SOC, not necessarily a group
>>> of devices on the same bus.  Could we simply list all those
>>> devices under an "soc" node at the same level.
>>
>> A "soc" node is meant to contain SoC specific stuff like
>> clock registers or whatnot.  It typically wouldn't have
>> child nodes.
>
> That's not what booting_without_of.txt says.  It says:
>
>     The SOC node may contain child nodes for each SOC
>     device that the  platform uses.

*May*.  There often is a better way to represent devices;
if they sit on some bus in reality, that's the best way
to describe them: by exposing that bus in the device tree.

> The current practice seems to be that an "soc" node contains
> all the on chip devices (regardless of the physical bus internal
> to the soc).

You can make the busses child nodes of the "soc" device
if you prefer.  I might even consider it good taste ;-)

>>> my suggestion would be to create new generic device type for
>>> representing an internal bus.   The "device_type" is supposed
>>> to be somewhat general-- "network", "serial", etc.
>>
>> The device_type represents the programming model of the
>> device (programming model for OF).
>
> The device_type is typically things like "network" and "serial"
> which don't specify the programming model.

The ___OF___ programming model, i.e. as you would use from
either of the client-, device- or user interface.  This
interface typically consists of a handful of properties
and device methods ("read", "seek", "max-transfer").

> The compatible
> property is used in driver selection.

For the OS, yes.

>> Each type of bus has
>> its own programming model.  Your suggestion makes sense
>> for bus bridges that are 100% transparent -- same address
>> domain on both sides, completely identical ordering rules,
>> no configuration whatsoever.  I've never seen such a bus.
>
> If the busses have different address domains and specific
> configuration then I agree, they need their own unique device_type.
>
> Do the ipb and opb busses have their own device driver similar to
> PCI?

Sigh.  Like I must have said 2**20 times now, it doesn't matter
if you currently have a certain Linux driver for something, nor
does it actually matter if there will ever be one.  I do know
that the OPB bus is different from the PLB bus and as such should
not be hidden.  Hey, it seems there are some DCR registers to
configure the thing if I remember the device tree that was posted
correctly.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[David Gibson]

On Wed, Feb 14, 2007 at 10:12:18PM +0100, Segher Boessenkool wrote:
[snip]
> The device_type represents the programming model of the
> device (programming model for OF).  Each type of bus has
> its own programming model.  Your suggestion makes sense
> for bus bridges that are 100% transparent -- same address
> domain on both sides, completely identical ordering rules,
> no configuration whatsoever.  I've never seen such a bus.

With that I think you convinced me to use separate device_type values
for each of the internal busses: if we had one of these with an actual
OF client interface, it's quite possible they would need different OF
interface models (for, e.g., changing the arbitration settings for the
OPB).

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 15/16] Add device tree for Ebony

[David Gibson]

On Wed, Feb 14, 2007 at 01:08:01PM -0700, Yoder Stuart-B08248 wrote:
>  
> > >> Hmm.  There are two "soc" devices here, one nested under the
> > >> first??
> > >>
> > >> I'm assuming these are two levels of busses the opb bus is attached
> > >> to the plb bus.  Is the "soc" device_type the right way to
> > >> do this?
> > >
> > > Right, OPB hangs off of PLB in this case.  I dunno if "soc" is the 
> > > right
> > > device type for them though.
> > 
> > I would use device_type "plb" (or "plb4") and "opb" I think.
> > Similar to how PCI and ISA etc. busses are represented.
> 
> I think we should avoid making up new device_types unlesss it
> really is necessary.
> 
> Is it really necessary to distinguish between devices on
> the PLB or OPB?

Well.. maybe.  There are registers (DCR, not MMIO) in the PLB<->OPB
bridge.  I don't think the actual mapping can be changed, but some
error reporting and arbitration are controller there.  I think it's
better to represent the two busses, in case the distinction becomes
important at some point.

> As I undestand it the "soc" device type is a logical container
> for a group of devices in an SOC, not necessarily a group
> of devices on the same bus.  Could we simply list all those
> devices under an "soc" node at the same level.
> 
> If for some reason the bus hierarchy distinction _is_ required,
> my suggestion would be to create new generic device type for
> representing an internal bus.   The "device_type" is supposed
> to be somewhat general-- "network", "serial", etc.
> 
> We could create something like "soc-bus" or "internal-bus" with
> a compatible field that identifies the type of bus.
> 
> The general philosophy is a general device_type prooperty and
> a specific compatible property.

Yes, that's partly why I'm using "soc" for now.  I've thought that a
new general device_type might be a good idea though.  What's a "soc"
and what's an "internal" bus I think are not necessarily clear,
though.  I would suggest a type for any memory mapped,
non-hotpluggable, non-probeable bus.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 15/16] Add device tree for Ebony

[David Gibson]

On Wed, Feb 14, 2007 at 06:58:04PM +0100, Segher Boessenkool wrote:
> >> Did you mean to have UIC1 nested under UIC0 or should
> >> they be at the same level?
> >
> > No, they are cascaded in hardware.  I think having UIC1 under UCI0 is a
> > correct representation.
> 
> Only the interrupt routing is cascaded AFAICS, and
> there is a separate interrupt tree to express that.

In the case of the UICs, I don't see that there's anything "only"
about the interrupt routing.  They're DCR controlled, and are not on
the normal bus.

> >> Hmm.  There are two "soc" devices here, one nested under the
> >> first??
> >>
> >> I'm assuming these are two levels of busses the opb bus is attached
> >> to the plb bus.  Is the "soc" device_type the right way to
> >> do this?
> >
> > Right, OPB hangs off of PLB in this case.  I dunno if "soc" is the 
> > right
> > device type for them though.
> 
> I would use device_type "plb" (or "plb4") and "opb" I think.
> Similar to how PCI and ISA etc. busses are represented.

Yeah, I've been pretty usnsure about this myself.  Using "soc" was
initially a hack to make the legacy serial detection stuff work, but I
think Arnd's of_platform serial stuff will deal with that better.

On the other hand, using separate device_type has no particular value,
either.  I wonder if we should have a general device_type for any
non-probeable, memory-mapped bus.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 15/16] Add device tree for Ebony

[Benjamin Herrenschmidt]

> Yeah, I've been pretty usnsure about this myself.  Using "soc" was
> initially a hack to make the legacy serial detection stuff work, but I
> think Arnd's of_platform serial stuff will deal with that better.
> 
> On the other hand, using separate device_type has no particular value,
> either.  I wonder if we should have a general device_type for any
> non-probeable, memory-mapped bus.

What about dumb-bus ? :-0

Ben.

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> On the other hand, using separate device_type has no particular value,
>> either.  I wonder if we should have a general device_type for any
>> non-probeable, memory-mapped bus.
>
> What about dumb-bus ? :-0

If the bus is really 100% transparent, who *cares* what
its device_type is, since it won't provide any information
to you that the empty "ranges" property doesn't already.

And if it's not, then you should show what type of bus
it is since clearly some information _is_ needed.

To make things easier, just always say what kind of
thing the bus really is :-)


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>>> No, they are cascaded in hardware.  I think having UIC1 under UCI0 
>>> is a
>>> correct representation.
>>
>> Only the interrupt routing is cascaded AFAICS, and
>> there is a separate interrupt tree to express that.
>
> In the case of the UICs, I don't see that there's anything "only"
> about the interrupt routing.  They're DCR controlled, and are not on
> the normal bus.

Yes.  UIC1 is not addressed via UIC0, and as such should
not be a child of it; it should be a direct child of its DCR
controller, just like UIC0.

The interrupt cascading should be expressed using the
interrupt mapping mechanism, which was designed expressly
for this purpose.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[David Gibson]

On Thu, Feb 15, 2007 at 01:31:36AM +0100, Segher Boessenkool wrote:
> >>> No, they are cascaded in hardware.  I think having UIC1 under UCI0 
> >>> is a
> >>> correct representation.
> >>
> >> Only the interrupt routing is cascaded AFAICS, and
> >> there is a separate interrupt tree to express that.
> >
> > In the case of the UICs, I don't see that there's anything "only"
> > about the interrupt routing.  They're DCR controlled, and are not on
> > the normal bus.
> 
> Yes.  UIC1 is not addressed via UIC0, and as such should
> not be a child of it; it should be a direct child of its DCR
> controller, just like UIC0.

No, the DCR tree, like the interrupt tree in most cases, is
independent of the main tree structure.  The ultimate DCR parent is
the CPU node.  I see no reason to prefer the DCR connection over the
interrupt connection for the nesting here.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> Yes.  UIC1 is not addressed via UIC0, and as such should
>> not be a child of it; it should be a direct child of its DCR
>> controller, just like UIC0.
>
> No, the DCR tree, like the interrupt tree in most cases, is
> independent of the main tree structure.

Yes true; you can hang the UICs from somewhere under the
"soc" node or whatever you want.  You need some way to
distinguish separate identical devices though; you can't
do it by device unit since your devices don't have any
(they don't have a "reg" but only a "dcr-reg").  If you
would hang them in a DCR tree, you could use the plain
"reg" property instead of the "dcr-reg" property and
all would be fine (if the DCR binding allows this -- and
it better should, it is the standard OF addressing algorithm).

However, my main point remains: the two interrupt controllers
should be siblings in the device tree, since they are that on
the hardware.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[David Gibson]

On Thu, Feb 15, 2007 at 04:09:15AM +0100, Segher Boessenkool wrote:
> >> Yes.  UIC1 is not addressed via UIC0, and as such should
> >> not be a child of it; it should be a direct child of its DCR
> >> controller, just like UIC0.
> >
> > No, the DCR tree, like the interrupt tree in most cases, is
> > independent of the main tree structure.
> 
> Yes true; you can hang the UICs from somewhere under the
> "soc" node or whatever you want.  You need some way to
> distinguish separate identical devices though; you can't
> do it by device unit since your devices don't have any
> (they don't have a "reg" but only a "dcr-reg").  If you
> would hang them in a DCR tree, you could use the plain
> "reg" property instead of the "dcr-reg" property and
> all would be fine (if the DCR binding allows this -- and
> it better should, it is the standard OF addressing algorithm).

No, doesn't work.  The trouble is there are other devices that *do*
sit on the normal MMIO bus, but also have DCRs (MAL, POB, SDRAM
controller).  The DCR tree has to cut across the normal bus tree, like
the interrupt tree.

> However, my main point remains: the two interrupt controllers
> should be siblings in the device tree, since they are that on
> the hardware.

In what way are they "that on the hardware".  They're siblings on the
DCR tree, they're parent/child on the interrupt tree.  Given that
they're not on the MMIO tree at all, I see no strong reason to pick
one representation over another.  I picked the interrupt tree, because
it seemed to make as much or more logical sense as the other, and as a
bonus it makes the probing logic easier.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> Yes true; you can hang the UICs from somewhere under the
>> "soc" node or whatever you want.  You need some way to
>> distinguish separate identical devices though; you can't
>> do it by device unit since your devices don't have any
>> (they don't have a "reg" but only a "dcr-reg").  If you
>> would hang them in a DCR tree, you could use the plain
>> "reg" property instead of the "dcr-reg" property and
>> all would be fine (if the DCR binding allows this -- and
>> it better should, it is the standard OF addressing algorithm).
>
> No, doesn't work.  The trouble is there are other devices that *do*
> sit on the normal MMIO bus, but also have DCRs (MAL, POB, SDRAM
> controller).  The DCR tree has to cut across the normal bus tree, like
> the interrupt tree.

Yes, and they can use "dcr-reg" properties just fine; compare
to how "interrupt-parent" works: nodes that can use the normal
tree rules don't need it, everything else does.

>> However, my main point remains: the two interrupt controllers
>> should be siblings in the device tree, since they are that on
>> the hardware.
>
> In what way are they "that on the hardware".  They're siblings on the
> DCR tree, they're parent/child on the interrupt tree.  Given that
> they're not on the MMIO tree at all, I see no strong reason to pick
> one representation over another.

It's not about MMIO; it's about addressability.  On many systems
almost none of the I/O subsystems primary address (config space
for PCI!) is on MMIO.

Quoting from OF1275:

> The device tree=92s structure mimics the organization of the system=20
> hardware, viewed as a hierarchy of interconnected buses and their=20
> attached devices.

The interrupt cascade is not a bus.

> I picked the interrupt tree, because
> it seemed to make as much or more logical sense as the other,

Yeah I know.

> and as a
> bonus it makes the probing logic easier.

How so?  There already is completely generic probing
code for interrupt controllers AFAIK.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Benjamin Herrenschmidt]

On Thu, 2007-02-15 at 04:09 +0100, Segher Boessenkool wrote:
> >> Yes.  UIC1 is not addressed via UIC0, and as such should
> >> not be a child of it; it should be a direct child of its DCR
> >> controller, just like UIC0.
> >
> > No, the DCR tree, like the interrupt tree in most cases, is
> > independent of the main tree structure.
> 
> Yes true; you can hang the UICs from somewhere under the
> "soc" node or whatever you want.  You need some way to
> distinguish separate identical devices though; you can't
> do it by device unit since your devices don't have any
> (they don't have a "reg" but only a "dcr-reg").  If you
> would hang them in a DCR tree, you could use the plain
> "reg" property instead of the "dcr-reg" property and
> all would be fine (if the DCR binding allows this -- and
> it better should, it is the standard OF addressing algorithm).

It's not as DCRs are orthogonal to the normal bus tree (yeah, it sucks
but that's how it is, broken by design :-)

For example, MAL is DMA'ing on PLB but controlled via DCRs.

> However, my main point remains: the two interrupt controllers
> should be siblings in the device tree, since they are that on
> the hardware.

Ben.

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>>> No, the DCR tree, like the interrupt tree in most cases, is
>>> independent of the main tree structure.
>>
>> Yes true; you can hang the UICs from somewhere under the
>> "soc" node or whatever you want.  You need some way to
>> distinguish separate identical devices though; you can't
>> do it by device unit since your devices don't have any
>> (they don't have a "reg" but only a "dcr-reg").  If you
>> would hang them in a DCR tree, you could use the plain
>> "reg" property instead of the "dcr-reg" property and
>> all would be fine (if the DCR binding allows this -- and
>> it better should, it is the standard OF addressing algorithm).
>
> It's not as DCRs are orthogonal to the normal bus tree (yeah, it sucks
> but that's how it is, broken by design :-)

Of course, I know that.  What I'm saying is that devices
where the *only* connection to the system is the DCR ring,
should use normal "reg" properties instead of "dcr-reg"
properties (and normal parent instead of "dcr-parent") to
describe the DCR registers, so that they get a valid unit
address.


Segher

Re: [PATCH 15/16] Add device tree for Ebony

[Benjamin Herrenschmidt]

On Thu, 2007-02-15 at 15:52 +0100, Segher Boessenkool wrote:
> >>> No, the DCR tree, like the interrupt tree in most cases, is
> >>> independent of the main tree structure.
> >>
> >> Yes true; you can hang the UICs from somewhere under the
> >> "soc" node or whatever you want.  You need some way to
> >> distinguish separate identical devices though; you can't
> >> do it by device unit since your devices don't have any
> >> (they don't have a "reg" but only a "dcr-reg").  If you
> >> would hang them in a DCR tree, you could use the plain
> >> "reg" property instead of the "dcr-reg" property and
> >> all would be fine (if the DCR binding allows this -- and
> >> it better should, it is the standard OF addressing algorithm).
> >
> > It's not as DCRs are orthogonal to the normal bus tree (yeah, it sucks
> > but that's how it is, broken by design :-)
> 
> Of course, I know that.  What I'm saying is that devices
> where the *only* connection to the system is the DCR ring,
> should use normal "reg" properties instead of "dcr-reg"
> properties (and normal parent instead of "dcr-parent") to
> describe the DCR registers, so that they get a valid unit
> address.

So you say that we shold have 2 different ways to encode a DCR mapping ?
Nah ....

Ben.

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

>> Of course, I know that.  What I'm saying is that devices
>> where the *only* connection to the system is the DCR ring,
>> should use normal "reg" properties instead of "dcr-reg"
>> properties (and normal parent instead of "dcr-parent") to
>> describe the DCR registers, so that they get a valid unit
>> address.
>
> So you say that we shold have 2 different ways to encode a DCR mapping 
> ?
> Nah ....

If you don't, and you have two identical devices sitting
on the same DCR bus (but not on an MMIO bus), you have
no way to distinguish them.  Oops.  You might not like it
but that's the DCR's fault, not mine :-)


Segher

RE: [PATCH 15/16] Add device tree for Ebony

[Yoder Stuart-B08248]

=20

> -----Original Message-----
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]=20
> Sent: Wednesday, February 14, 2007 9:09 PM
> To: David Gibson
> Cc: linuxppc-dev@ozlabs.org; Yoder Stuart-B08248
> Subject: Re: [PATCH 15/16] Add device tree for Ebony
>=20
> >> Yes.  UIC1 is not addressed via UIC0, and as such should
> >> not be a child of it; it should be a direct child of its DCR
> >> controller, just like UIC0.
> >
> > No, the DCR tree, like the interrupt tree in most cases, is
> > independent of the main tree structure.
>=20
> Yes true; you can hang the UICs from somewhere under the
> "soc" node or whatever you want.  You need some way to
> distinguish separate identical devices though; you can't
> do it by device unit since your devices don't have any
> (they don't have a "reg" but only a "dcr-reg").  If you
> would hang them in a DCR tree, you could use the plain
> "reg" property instead of the "dcr-reg" property and
> all would be fine (if the DCR binding allows this -- and
> it better should, it is the standard OF addressing algorithm).

Is there a DCR binding?  Are the dcr-* properties documented=20
anywhere:

dcr-reg         // what do these fields mean?
dcr-parent      // in case there is more than one controller??
dcr-controller
dcr-access-method =3D "native"   // what are the other options?

Stuart

RE: [PATCH 15/16] Add device tree for Ebony

[Benjamin Herrenschmidt]

> Is there a DCR binding?  Are the dcr-* properties documented 
> anywhere:
> 
> dcr-reg         // what do these fields mean?
> dcr-parent      // in case there is more than one controller??
> dcr-controller
> dcr-access-method = "native"   // what are the other options?

Yes, we wrote a binding document though I can't find it now. Hartmut or
Heiko, do you have the latest DCR binding document at hand ?

dcr-reg is akin to "reg", it is a list of [dcr numbers, number of dcr]
for a device.

dcr-parent is a phandle to the dcr "controller" or "master" that
generate the DCR cycles

dcr-controller is like "interrupt-controller", it's a property to slap
into any node that is also a dcr-controller. Typically, this can be the
core for a 4xx processor or a separate device for Axon

dcr-access-method can be "native" for 4xx or "mmio" for Axon-type MMIO
mapped DCR bus.

The parent linkage is necessary when using things ike Axon since more
than one Axon can be present in a system, thus more than one MMIO->DCR
"converters" providing each a separate DCR space for controller a
separate set of devices.

Ben

Re: [PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

> dcr-access-method can be "native" for 4xx or "mmio" for Axon-type MMIO
> mapped DCR bus.

Why is this one needed btw?  Surely the "compatible" property
of the DCR controller node will tell you how to access the
DCR bus already.  Also, both "native" and "mmio" are way too
generic names.


Segher

RE: [PATCH 15/16] Add device tree for Ebony

[Hartmut Penner]

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

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 15.02.2007 
22:41:08:

> 
> > Is there a DCR binding?  Are the dcr-* properties documented 
> > anywhere:
> > 
> > dcr-reg         // what do these fields mean?
> > dcr-parent      // in case there is more than one controller??
> > dcr-controller
> > dcr-access-method = "native"   // what are the other options?
> 
> Yes, we wrote a binding document though I can't find it now. Hartmut or
> Heiko, do you have the latest DCR binding document at hand ?

I found some draft. It is as you discribed here. I need to check, how 
close this
is to what we did at last. Also we need place were we can publish such a 
document ...

> 
> dcr-reg is akin to "reg", it is a list of [dcr numbers, number of dcr]
> for a device.
> 
> dcr-parent is a phandle to the dcr "controller" or "master" that
> generate the DCR cycles
> 
> dcr-controller is like "interrupt-controller", it's a property to slap
> into any node that is also a dcr-controller. Typically, this can be the
> core for a 4xx processor or a separate device for Axon
> 
> dcr-access-method can be "native" for 4xx or "mmio" for Axon-type MMIO
> mapped DCR bus.
> 
> The parent linkage is necessary when using things ike Axon since more
> than one Axon can be present in a system, thus more than one MMIO->DCR
> "converters" providing each a separate DCR space for controller a
> separate set of devices.
> 
> Ben
> 

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

RE: [PATCH 15/16] Add device tree for Ebony

[Yoder Stuart-B08248]

> Harmut Pennter wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 15.02.2007
22:41:08:
>=20
> >=20
> > > Is there a DCR binding?  Are the dcr-* properties documented=20
> > > anywhere:
> > >=20
> > > dcr-reg         // what do these fields mean?
> > > dcr-parent      // in case there is more than one controller??
> > > dcr-controller
> > > dcr-access-method =3D "native"   // what are the other options?
> >=20
> > Yes, we wrote a binding document though I can't find it now. Hartmut
or
> > Heiko, do you have the latest DCR binding document at hand ?
>=20
> I found some draft. It is as you discribed here. I need to check, how
close this=20
> is to what we did at last. Also we need place were we can publish such
a document ...=20

Harmut,

I would suggest creating a text file and putting this in
Documentation/powerpc along with booting-without-of.txt and
mpc52xx-device-tree-bindings.txt.

That is the closest place we have to a centralized repository
at this point.  Hopefully, in the near future power.org will
provide a repository outside of the Linux kernel source.

Stuart

RE: [PATCH 15/16] Add device tree for Ebony

[Hartmut Penner]

"Yoder Stuart-B08248" <stuart.yoder@freescale.com> wrote on 02/16/2007
05:47:51 PM:

>
> > Harmut Pennter wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 15.02.2007
> 22:41:08:
> >
> > >
> > > > Is there a DCR binding?  Are the dcr-* properties documented
> > > > anywhere:
> > > >
> > > > dcr-reg         // what do these fields mean?
> > > > dcr-parent      // in case there is more than one controller??
> > > > dcr-controller
> > > > dcr-access-method = "native"   // what are the other options?
> > >
> > > Yes, we wrote a binding document though I can't find it now. Hartmut
> or
> > > Heiko, do you have the latest DCR binding document at hand ?
> >
> > I found some draft. It is as you discribed here. I need to check, how
> close this
> > is to what we did at last. Also we need place were we can publish such
> a document ...
>
> Harmut,
>
> I would suggest creating a text file and putting this in
> Documentation/powerpc along with booting-without-of.txt and
> mpc52xx-device-tree-bindings.txt.
>
> That is the closest place we have to a centralized repository
> at this point.  Hopefully, in the near future power.org will
> provide a repository outside of the Linux kernel source.

Stuart,
      I have looked into the document and the FW code and will update the
document with
our latest de-facto bindings we developed together with Ben. Were and how
we put it out,
I need to discuss first internally.

      regards, Hartmut

>
> Stuart

RE: [PATCH 15/16] Add device tree for Ebony

[Benjamin Herrenschmidt]

> Right, OPB hangs off of PLB in this case.  I dunno if "soc" is the right
> device type for them though.

I'm no fan of "soc" anyway... plb could have device type "plb" and opb
"opb" :-) Or ibm,plb-bus and ibm,opb-bus ... (For axon, plb5 is plb5,
plb4 is plb4 and opb is opb).

Ben.

[PATCH 16/16] Support for Ebony in arch/powerpc

[David Gibson]

This patch adds platform support code for the Ebony (440GP) evaluation
board.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
---

 arch/powerpc/platforms/4xx/Kconfig  |    3 +
 arch/powerpc/platforms/4xx/Makefile |    2 -
 arch/powerpc/platforms/4xx/ebony.c  |   68 ++++++++++++++++++++++++++++++++++++
 3 files changed, 71 insertions(+), 2 deletions(-)

Index: working-2.6/arch/powerpc/platforms/4xx/Makefile
===================================================================
--- working-2.6.orig/arch/powerpc/platforms/4xx/Makefile	2007-02-13 12:37:37.000000000 +1100
+++ working-2.6/arch/powerpc/platforms/4xx/Makefile	2007-02-13 12:39:02.000000000 +1100
@@ -1 +1 @@
-# empty makefile so make clean works
\ No newline at end of file
+obj-$(CONFIG_EBONY)	:= ebony.o
Index: working-2.6/arch/powerpc/platforms/4xx/ebony.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ working-2.6/arch/powerpc/platforms/4xx/ebony.c	2007-02-13 12:39:02.000000000 +1100
@@ -0,0 +1,68 @@
+/*
+ * Ebony board specific routines
+ *
+ * Matt Porter <mporter@kernel.crashing.org>
+ * Copyright 2002-2005 MontaVista Software Inc.
+ *
+ * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
+ * Copyright (c) 2003-2005 Zultys Technologies
+ *
+ * Rewritten and ported to the merged powerpc tree:
+ * Copyright 2007 David Gibson <dwg@au1.ibm.com>, IBM Corporation.
+ *
+ * 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.
+ */
+
+#include <linux/init.h>
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+#include <asm/of_platform.h>
+
+static struct of_device_id ebony_of_bus[] = {
+	{ .type = "soc", },
+	{},
+};
+
+static int __init ebony_device_probe(void)
+{
+	if (! machine_is(ebony))
+		return 0;
+
+	of_platform_bus_probe(NULL, ebony_of_bus, NULL);
+
+	return 0;
+}
+device_initcall(ebony_device_probe);
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init ebony_probe(void)
+{
+	unsigned long root = of_get_flat_dt_root();
+
+	if (!of_flat_dt_is_compatible(root, "Ebony"))
+		return 0;
+
+	return 1;
+}
+
+static void __init ebony_setup_arch(void)
+{
+}
+
+define_machine(ebony) {
+	.name			= "Ebony",
+	.probe			= ebony_probe,
+	.setup_arch		= ebony_setup_arch,
+	.progress		= udbg_progress,
+	.init_IRQ		= uic_init_tree,
+	.get_irq		= uic_get_irq,
+	.calibrate_decr		= generic_calibrate_decr,
+};
Index: working-2.6/arch/powerpc/platforms/4xx/Kconfig
===================================================================
--- working-2.6.orig/arch/powerpc/platforms/4xx/Kconfig	2007-02-13 12:37:37.000000000 +1100
+++ working-2.6/arch/powerpc/platforms/4xx/Kconfig	2007-02-13 12:39:02.000000000 +1100
@@ -112,7 +112,8 @@ config 440EP
 config 440GP
 	bool
 	depends on EBONY
-	default y
+	select IBM_NEW_EMAC_ZMII
+ 	default y
 
 config 440GX
 	bool

Re: [PATCH 16/16] Support for Ebony in arch/powerpc

[Roland Dreier]

 >  config 440GP
 >  	bool
 >  	depends on EBONY
 > -	default y
 > +	select IBM_NEW_EMAC_ZMII
 > + 	default y

Maybe we could take this opportunity to clean up the CPU selection in
Kconfig and use select instead... right now we have a mess like

config 440GP
        bool
        depends on EBONY
        default y

config 440
        bool
        depends on 440GP || 440SP || 440SPE || 440EP
        default y

etc... -- it would be nice for this to look like

config EBONY
	bool
	select 440GP

config 440GP
	bool
	select IBM_NEW_EMAC_ZMII
	select 440

config 440
	bool

I'm happy to do this cleanup after things settle down though

Re: [PATCH 16/16] Support for Ebony in arch/powerpc

[David Gibson]

On Tue, Feb 13, 2007 at 09:18:57AM -0800, Roland Dreier wrote:
>  >  config 440GP
>  >  	bool
>  >  	depends on EBONY
>  > -	default y
>  > +	select IBM_NEW_EMAC_ZMII
>  > + 	default y
> 
> Maybe we could take this opportunity to clean up the CPU selection in
> Kconfig and use select instead... right now we have a mess like
> 
> config 440GP
>         bool
>         depends on EBONY
>         default y
> 
> config 440
>         bool
>         depends on 440GP || 440SP || 440SPE || 440EP
>         default y
> 
> etc... -- it would be nice for this to look like
> 
> config EBONY
> 	bool
> 	select 440GP
> 
> config 440GP
> 	bool
> 	select IBM_NEW_EMAC_ZMII
> 	select 440
> 
> config 440
> 	bool
> 
> I'm happy to do this cleanup after things settle down though

Yes, I've been thinking about something like that.  Sounds good to
me.  At the same time we need to change the board options from a
choice to individual bools, since it should now be possible to make a
kernel bootable on multiple boards.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [0/16] Preliminary Ebony (440GP) support for arch/powerpc

[Josh Boyer]

On Tue, 2007-02-13 at 17:09 +1100, David Gibson wrote:
> Here is a preliminary set of patches implementing support for the
> 440GP based Ebony evaluation board in arch/powerpc.  A number of the
> earlier patches are in Paul's queue already, so may appear in
> powerpc.git at any point.  Most of the later ones need at least some
> cleanup or reworking before they'll be ready for merging.
> 
> With these patches I can boot to a shell prompt on initrd on my Ebony
> board.  There are still a bunch of problems: clock timings are way out
> (runs about 4* fast), things freeze up when I attempt to use an
> nfsroot, many devices aren't supported.  A lot of things are hardcoded
> in the device tree, so you may well have to tweak it if your Ebony is
> different from mine.

FYI, these patches seem to want Ben's EMAC rewrite patch as well.  They
select Kconfig options that aren't present until that patch is applied.

We're also missing an arch/powerpc/configs/ebony_defconfig.

josh

Re: [0/16] Preliminary Ebony (440GP) support for arch/powerpc

[Josh Boyer]

On Tue, 2007-02-13 at 08:37 -0600, Josh Boyer wrote:
> 
> We're also missing an arch/powerpc/configs/ebony_defconfig.

So here's the defconfig I've been using.  It should work, but David
might have a better one.

josh



Add defconfig for Ebony board to arch/powerpc

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---
 arch/powerpc/configs/ebony_defconfig |  933 +++++++++++++++++++++++++++++++++++
 1 file changed, 933 insertions(+)

--- /dev/null
+++ linux-2.6/arch/powerpc/configs/ebony_defconfig
@@ -0,0 +1,933 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.20
+# Tue Feb 13 09:54:36 2007
+#
+# CONFIG_PPC64 is not set
+CONFIG_PPC32=y
+CONFIG_PPC_MERGE=y
+CONFIG_MMU=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_IRQ_PER_CPU=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_ARCH_HAS_ILOG2_U32=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
+CONFIG_PPC=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_PPC_OF=y
+# CONFIG_PPC_UDBG_16550 is not set
+# CONFIG_GENERIC_TBSYNC is not set
+CONFIG_AUDIT_ARCH=y
+CONFIG_GENERIC_BUG=y
+# CONFIG_DEFAULT_UIMAGE is not set
+
+#
+# Processor support
+#
+# CONFIG_CLASSIC32 is not set
+# CONFIG_PPC_82xx is not set
+# CONFIG_PPC_83xx is not set
+# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_86xx is not set
+# CONFIG_PPC_8xx is not set
+# CONFIG_40x is not set
+CONFIG_44x=y
+# CONFIG_E200 is not set
+CONFIG_PPC_DCR_NATIVE=y
+# CONFIG_PPC_DCR_MMIO is not set
+CONFIG_PPC_DCR=y
+CONFIG_BOOKE=y
+CONFIG_PTE_64BIT=y
+CONFIG_PHYS_64BIT=y
+CONFIG_NOT_COHERENT_CACHE=y
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+
+#
+# Code maturity level options
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+
+#
+# General setup
+#
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+# CONFIG_IPC_NS is not set
+CONFIG_POSIX_MQUEUE=y
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_UTS_NS is not set
+# CONFIG_AUDIT is not set
+# CONFIG_IKCONFIG is not set
+CONFIG_SYSFS_DEPRECATED=y
+# CONFIG_RELAY is not set
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_SYSCTL=y
+CONFIG_EMBEDDED=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_EPOLL=y
+CONFIG_SHMEM=y
+CONFIG_SLAB=y
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+# CONFIG_SLOB is not set
+
+#
+# Loadable module support
+#
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_KMOD=y
+
+#
+# Block layer
+#
+CONFIG_BLOCK=y
+CONFIG_LBD=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="anticipatory"
+CONFIG_PPC_GEN550=y
+CONFIG_4xx=y
+CONFIG_WANT_EARLY_SERIAL=y
+
+#
+# AMCC 4xx options
+#
+# CONFIG_BAMBOO is not set
+CONFIG_EBONY=y
+# CONFIG_LUAN is not set
+# CONFIG_OCOTEA is not set
+CONFIG_440GP=y
+CONFIG_440=y
+CONFIG_IBM_OCP=y
+# CONFIG_PPC4xx_DMA is not set
+# CONFIG_MPIC is not set
+
+#
+# Kernel options
+#
+# CONFIG_HIGHMEM is not set
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_300 is not set
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+# CONFIG_MATH_EMULATION is not set
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+# CONFIG_PC_KEYBOARD is not set
+CONFIG_ARCH_FLATMEM_ENABLE=y
+CONFIG_ARCH_POPULATES_NODE_MAP=y
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_RESOURCES_64BIT=y
+CONFIG_ZONE_DMA_FLAG=1
+# CONFIG_PROC_DEVICETREE is not set
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE="ip=on"
+CONFIG_SECCOMP=y
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+CONFIG_ZONE_DMA=y
+# CONFIG_MPIC_WEIRD is not set
+# CONFIG_PPC_I8259 is not set
+CONFIG_PPC_INDIRECT_PCI=y
+CONFIG_PCI=y
+CONFIG_PCI_DOMAINS=y
+# CONFIG_PCIEPORTBUS is not set
+# CONFIG_PCI_DEBUG is not set
+
+#
+# PCCARD (PCMCIA/CardBus) support
+#
+# CONFIG_PCCARD is not set
+
+#
+# PCI Hotplug Support
+#
+# CONFIG_HOTPLUG_PCI is not set
+
+#
+# Advanced setup
+#
+# CONFIG_ADVANCED_OPTIONS is not set
+
+#
+# Default settings for advanced configuration options are used
+#
+CONFIG_HIGHMEM_START=0xfe000000
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_TASK_SIZE=0x80000000
+CONFIG_CONSISTENT_START=0xff100000
+CONFIG_CONSISTENT_SIZE=0x00200000
+CONFIG_BOOT_LOAD=0x01000000
+
+#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+# CONFIG_NETDEBUG is not set
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+CONFIG_XFRM=y
+# CONFIG_XFRM_USER is not set
+# CONFIG_XFRM_SUB_POLICY is not set
+# CONFIG_XFRM_MIGRATE is not set
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+# CONFIG_IP_MULTICAST is not set
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+# CONFIG_IP_PNP_DHCP is not set
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_ARPD is not set
+# CONFIG_SYN_COOKIES is not set
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_XFRM_TUNNEL is not set
+# CONFIG_INET_TUNNEL is not set
+CONFIG_INET_XFRM_MODE_TRANSPORT=y
+CONFIG_INET_XFRM_MODE_TUNNEL=y
+CONFIG_INET_XFRM_MODE_BEET=y
+CONFIG_INET_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_CUBIC=y
+CONFIG_DEFAULT_TCP_CONG="cubic"
+# CONFIG_TCP_MD5SIG is not set
+
+#
+# IP: Virtual Server Configuration
+#
+# CONFIG_IP_VS is not set
+# CONFIG_IPV6 is not set
+# CONFIG_INET6_XFRM_TUNNEL is not set
+# CONFIG_INET6_TUNNEL is not set
+# CONFIG_NETWORK_SECMARK is not set
+CONFIG_NETFILTER=y
+# CONFIG_NETFILTER_DEBUG is not set
+
+#
+# Core Netfilter Configuration
+#
+# CONFIG_NETFILTER_NETLINK is not set
+# CONFIG_NF_CONNTRACK_ENABLED is not set
+# CONFIG_NETFILTER_XTABLES is not set
+
+#
+# IP: Netfilter Configuration
+#
+# CONFIG_IP_NF_QUEUE is not set
+# CONFIG_IP_NF_IPTABLES is not set
+# CONFIG_IP_NF_ARPTABLES is not set
+
+#
+# DCCP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_DCCP is not set
+
+#
+# SCTP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_SCTP is not set
+
+#
+# TIPC Configuration (EXPERIMENTAL)
+#
+# CONFIG_TIPC is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+
+#
+# QoS and/or fair queueing
+#
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_IEEE80211 is not set
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+CONFIG_STANDALONE=y
+CONFIG_PREVENT_FIRMWARE_BUILD=y
+CONFIG_FW_LOADER=y
+# CONFIG_DEBUG_DRIVER is not set
+# CONFIG_DEBUG_DEVRES is not set
+# CONFIG_SYS_HYPERVISOR is not set
+
+#
+# Connector - unified userspace <-> kernelspace linker
+#
+CONFIG_CONNECTOR=y
+CONFIG_PROC_EVENTS=y
+
+#
+# Memory Technology Devices (MTD)
+#
+# CONFIG_MTD is not set
+
+#
+# Parallel port support
+#
+# CONFIG_PARPORT is not set
+
+#
+# Plug and Play support
+#
+
+#
+# Block devices
+#
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_CPQ_DA is not set
+# CONFIG_BLK_CPQ_CISS_DA is not set
+# CONFIG_BLK_DEV_DAC960 is not set
+# CONFIG_BLK_DEV_UMEM is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+# CONFIG_BLK_DEV_LOOP is not set
+# CONFIG_BLK_DEV_NBD is not set
+# CONFIG_BLK_DEV_SX8 is not set
+# CONFIG_BLK_DEV_RAM is not set
+# CONFIG_BLK_DEV_INITRD is not set
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+
+#
+# Misc devices
+#
+# CONFIG_SGI_IOC4 is not set
+# CONFIG_TIFM_CORE is not set
+
+#
+# ATA/ATAPI/MFM/RLL support
+#
+# CONFIG_IDE is not set
+
+#
+# SCSI device support
+#
+# CONFIG_RAID_ATTRS is not set
+# CONFIG_SCSI is not set
+# CONFIG_SCSI_NETLINK is not set
+
+#
+# Serial ATA (prod) and Parallel ATA (experimental) drivers
+#
+# CONFIG_ATA is not set
+
+#
+# Multi-device support (RAID and LVM)
+#
+# CONFIG_MD is not set
+
+#
+# Fusion MPT device support
+#
+# CONFIG_FUSION is not set
+
+#
+# IEEE 1394 (FireWire) support
+#
+# CONFIG_IEEE1394 is not set
+
+#
+# I2O device support
+#
+# CONFIG_I2O is not set
+
+#
+# Macintosh device drivers
+#
+# CONFIG_MAC_EMUMOUSEBTN is not set
+# CONFIG_WINDFARM is not set
+
+#
+# Network device support
+#
+CONFIG_NETDEVICES=y
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+
+#
+# ARCnet devices
+#
+# CONFIG_ARCNET is not set
+
+#
+# PHY device support
+#
+
+#
+# Ethernet (10 or 100Mbit)
+#
+# CONFIG_NET_ETHERNET is not set
+# CONFIG_IBM_NEW_EMAC is not set
+CONFIG_IBM_NEW_EMAC_ZMII=y
+# CONFIG_IBM_NEW_EMAC_RGMII is not set
+# CONFIG_IBM_NEW_EMAC_TAH is not set
+# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
+
+#
+# Ethernet (1000 Mbit)
+#
+# CONFIG_ACENIC is not set
+# CONFIG_DL2K is not set
+# CONFIG_E1000 is not set
+# CONFIG_NS83820 is not set
+# CONFIG_HAMACHI is not set
+# CONFIG_YELLOWFIN is not set
+# CONFIG_R8169 is not set
+# CONFIG_SIS190 is not set
+# CONFIG_SKGE is not set
+# CONFIG_SKY2 is not set
+# CONFIG_SK98LIN is not set
+# CONFIG_TIGON3 is not set
+# CONFIG_BNX2 is not set
+# CONFIG_QLA3XXX is not set
+
+#
+# Ethernet (10000 Mbit)
+#
+# CONFIG_CHELSIO_T1 is not set
+# CONFIG_CHELSIO_T3 is not set
+# CONFIG_IXGB is not set
+# CONFIG_S2IO is not set
+# CONFIG_MYRI10GE is not set
+# CONFIG_NETXEN_NIC is not set
+
+#
+# Token Ring devices
+#
+# CONFIG_TR is not set
+
+#
+# Wireless LAN (non-hamradio)
+#
+# CONFIG_NET_RADIO is not set
+
+#
+# Wan interfaces
+#
+# CONFIG_WAN is not set
+# CONFIG_FDDI is not set
+# CONFIG_HIPPI is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+# CONFIG_SHAPER is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+
+#
+# ISDN subsystem
+#
+# CONFIG_ISDN is not set
+
+#
+# Telephony Support
+#
+# CONFIG_PHONE is not set
+
+#
+# Input device support
+#
+CONFIG_INPUT=y
+# CONFIG_INPUT_FF_MEMLESS is not set
+
+#
+# Userland interfaces
+#
+CONFIG_INPUT_MOUSEDEV=y
+CONFIG_INPUT_MOUSEDEV_PSAUX=y
+CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
+CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
+# CONFIG_INPUT_JOYDEV is not set
+# CONFIG_INPUT_TSDEV is not set
+# CONFIG_INPUT_EVDEV is not set
+# CONFIG_INPUT_EVBUG is not set
+
+#
+# Input Device Drivers
+#
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_INPUT_JOYSTICK is not set
+# CONFIG_INPUT_TOUCHSCREEN is not set
+# CONFIG_INPUT_MISC is not set
+
+#
+# Hardware I/O ports
+#
+CONFIG_SERIO=y
+# CONFIG_SERIO_I8042 is not set
+# CONFIG_SERIO_SERPORT is not set
+# CONFIG_SERIO_PCIPS2 is not set
+# CONFIG_SERIO_LIBPS2 is not set
+# CONFIG_SERIO_RAW is not set
+# CONFIG_GAMEPORT is not set
+
+#
+# Character devices
+#
+# CONFIG_VT is not set
+# CONFIG_SERIAL_NONSTANDARD is not set
+
+#
+# Serial drivers
+#
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_PCI=y
+CONFIG_SERIAL_8250_NR_UARTS=4
+CONFIG_SERIAL_8250_RUNTIME_UARTS=4
+CONFIG_SERIAL_8250_EXTENDED=y
+# CONFIG_SERIAL_8250_MANY_PORTS is not set
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+# CONFIG_SERIAL_8250_DETECT_IRQ is not set
+# CONFIG_SERIAL_8250_RSA is not set
+
+#
+# Non-8250 serial port support
+#
+# CONFIG_SERIAL_UARTLITE is not set
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+# CONFIG_SERIAL_JSM is not set
+CONFIG_UNIX98_PTYS=y
+# CONFIG_LEGACY_PTYS is not set
+
+#
+# IPMI
+#
+# CONFIG_IPMI_HANDLER is not set
+
+#
+# Watchdog Cards
+#
+# CONFIG_WATCHDOG is not set
+CONFIG_HW_RANDOM=y
+# CONFIG_NVRAM is not set
+# CONFIG_GEN_RTC is not set
+# CONFIG_DTLK is not set
+# CONFIG_R3964 is not set
+# CONFIG_APPLICOM is not set
+# CONFIG_AGP is not set
+# CONFIG_DRM is not set
+# CONFIG_RAW_DRIVER is not set
+
+#
+# TPM devices
+#
+# CONFIG_TCG_TPM is not set
+
+#
+# I2C support
+#
+# CONFIG_I2C is not set
+
+#
+# SPI support
+#
+# CONFIG_SPI is not set
+# CONFIG_SPI_MASTER is not set
+
+#
+# Dallas's 1-wire bus
+#
+# CONFIG_W1 is not set
+
+#
+# Hardware Monitoring support
+#
+# CONFIG_HWMON is not set
+# CONFIG_HWMON_VID is not set
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+
+#
+# Digital Video Broadcasting Devices
+#
+# CONFIG_DVB is not set
+
+#
+# Graphics support
+#
+CONFIG_FIRMWARE_EDID=y
+# CONFIG_FB is not set
+# CONFIG_FB_IBM_GXT4500 is not set
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+
+#
+# HID Devices
+#
+# CONFIG_HID is not set
+
+#
+# USB support
+#
+CONFIG_USB_ARCH_HAS_HCD=y
+CONFIG_USB_ARCH_HAS_OHCI=y
+CONFIG_USB_ARCH_HAS_EHCI=y
+# CONFIG_USB is not set
+
+#
+# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
+#
+
+#
+# USB Gadget Support
+#
+# CONFIG_USB_GADGET is not set
+
+#
+# MMC/SD Card support
+#
+# CONFIG_MMC is not set
+
+#
+# LED devices
+#
+# CONFIG_NEW_LEDS is not set
+
+#
+# LED drivers
+#
+
+#
+# LED Triggers
+#
+
+#
+# InfiniBand support
+#
+# CONFIG_INFINIBAND is not set
+
+#
+# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
+#
+
+#
+# Real Time Clock
+#
+# CONFIG_RTC_CLASS is not set
+
+#
+# DMA Engine support
+#
+# CONFIG_DMA_ENGINE is not set
+
+#
+# DMA Clients
+#
+
+#
+# DMA Devices
+#
+
+#
+# Auxiliary Display support
+#
+
+#
+# Virtualization
+#
+
+#
+# File systems
+#
+# CONFIG_EXT2_FS is not set
+# CONFIG_EXT3_FS is not set
+# CONFIG_EXT4DEV_FS is not set
+# CONFIG_REISERFS_FS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+# CONFIG_XFS_FS is not set
+# CONFIG_GFS2_FS is not set
+# CONFIG_OCFS2_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_ROMFS_FS is not set
+CONFIG_INOTIFY=y
+CONFIG_INOTIFY_USER=y
+# CONFIG_QUOTA is not set
+CONFIG_DNOTIFY=y
+# CONFIG_AUTOFS_FS is not set
+# CONFIG_AUTOFS4_FS is not set
+# CONFIG_FUSE_FS is not set
+
+#
+# CD-ROM/DVD Filesystems
+#
+# CONFIG_ISO9660_FS is not set
+# CONFIG_UDF_FS is not set
+
+#
+# DOS/FAT/NT Filesystems
+#
+# CONFIG_MSDOS_FS is not set
+# CONFIG_VFAT_FS is not set
+# CONFIG_NTFS_FS is not set
+
+#
+# Pseudo filesystems
+#
+CONFIG_PROC_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_PROC_SYSCTL=y
+CONFIG_SYSFS=y
+CONFIG_TMPFS=y
+# CONFIG_TMPFS_POSIX_ACL is not set
+# CONFIG_HUGETLB_PAGE is not set
+CONFIG_RAMFS=y
+# CONFIG_CONFIGFS_FS is not set
+
+#
+# Miscellaneous filesystems
+#
+# CONFIG_ADFS_FS is not set
+# CONFIG_AFFS_FS is not set
+# CONFIG_HFS_FS is not set
+# CONFIG_HFSPLUS_FS is not set
+# CONFIG_BEFS_FS is not set
+# CONFIG_BFS_FS is not set
+# CONFIG_EFS_FS is not set
+CONFIG_CRAMFS=y
+# CONFIG_VXFS_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+
+#
+# Network File Systems
+#
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+# CONFIG_NFS_V3_ACL is not set
+CONFIG_NFS_V4=y
+CONFIG_NFS_DIRECTIO=y
+# CONFIG_NFSD is not set
+CONFIG_ROOT_NFS=y
+CONFIG_LOCKD=y
+CONFIG_LOCKD_V4=y
+CONFIG_NFS_COMMON=y
+CONFIG_SUNRPC=y
+CONFIG_SUNRPC_GSS=y
+CONFIG_RPCSEC_GSS_KRB5=y
+# CONFIG_RPCSEC_GSS_SPKM3 is not set
+# CONFIG_SMB_FS is not set
+# CONFIG_CIFS is not set
+# CONFIG_NCP_FS is not set
+# CONFIG_CODA_FS is not set
+# CONFIG_AFS_FS is not set
+# CONFIG_9P_FS is not set
+
+#
+# Partition Types
+#
+# CONFIG_PARTITION_ADVANCED is not set
+CONFIG_MSDOS_PARTITION=y
+
+#
+# Native Language Support
+#
+# CONFIG_NLS is not set
+
+#
+# Distributed Lock Manager
+#
+# CONFIG_DLM is not set
+
+#
+# Library routines
+#
+CONFIG_BITREVERSE=y
+# CONFIG_CRC_CCITT is not set
+# CONFIG_CRC16 is not set
+CONFIG_CRC32=y
+# CONFIG_LIBCRC32C is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_PLIST=y
+CONFIG_HAS_IOMEM=y
+CONFIG_HAS_IOPORT=y
+
+#
+# Instrumentation Support
+#
+# CONFIG_PROFILING is not set
+
+#
+# Kernel hacking
+#
+CONFIG_PRINTK_TIME=y
+CONFIG_ENABLE_MUST_CHECK=y
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_UNUSED_SYMBOLS is not set
+# CONFIG_DEBUG_FS is not set
+# CONFIG_HEADERS_CHECK is not set
+CONFIG_DEBUG_KERNEL=y
+# CONFIG_DEBUG_SHIRQ is not set
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_DETECT_SOFTLOCKUP=y
+# CONFIG_SCHEDSTATS is not set
+# CONFIG_DEBUG_SLAB is not set
+# CONFIG_DEBUG_RT_MUTEXES is not set
+# CONFIG_RT_MUTEX_TESTER is not set
+# CONFIG_DEBUG_SPINLOCK is not set
+# CONFIG_DEBUG_MUTEXES is not set
+# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
+# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
+# CONFIG_DEBUG_KOBJECT is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_DEBUG_INFO is not set
+# CONFIG_DEBUG_VM is not set
+# CONFIG_DEBUG_LIST is not set
+CONFIG_FORCED_INLINING=y
+# CONFIG_RCU_TORTURE_TEST is not set
+# CONFIG_DEBUG_STACKOVERFLOW is not set
+# CONFIG_DEBUG_STACK_USAGE is not set
+CONFIG_DEBUGGER=y
+# CONFIG_KGDB is not set
+# CONFIG_XMON is not set
+# CONFIG_BDI_SWITCH is not set
+# CONFIG_BOOTX_TEXT is not set
+# CONFIG_PPC_EARLY_DEBUG is not set
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+
+#
+# Cryptographic options
+#
+CONFIG_CRYPTO=y
+CONFIG_CRYPTO_ALGAPI=y
+CONFIG_CRYPTO_BLKCIPHER=y
+CONFIG_CRYPTO_MANAGER=y
+# CONFIG_CRYPTO_HMAC is not set
+# CONFIG_CRYPTO_XCBC is not set
+# CONFIG_CRYPTO_NULL is not set
+# CONFIG_CRYPTO_MD4 is not set
+CONFIG_CRYPTO_MD5=y
+# CONFIG_CRYPTO_SHA1 is not set
+# CONFIG_CRYPTO_SHA256 is not set
+# CONFIG_CRYPTO_SHA512 is not set
+# CONFIG_CRYPTO_WP512 is not set
+# CONFIG_CRYPTO_TGR192 is not set
+# CONFIG_CRYPTO_GF128MUL is not set
+CONFIG_CRYPTO_ECB=m
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_PCBC=m
+# CONFIG_CRYPTO_LRW is not set
+CONFIG_CRYPTO_DES=y
+# CONFIG_CRYPTO_FCRYPT is not set
+# CONFIG_CRYPTO_BLOWFISH is not set
+# CONFIG_CRYPTO_TWOFISH is not set
+# CONFIG_CRYPTO_SERPENT is not set
+# CONFIG_CRYPTO_AES is not set
+# CONFIG_CRYPTO_CAST5 is not set
+# CONFIG_CRYPTO_CAST6 is not set
+# CONFIG_CRYPTO_TEA is not set
+# CONFIG_CRYPTO_ARC4 is not set
+# CONFIG_CRYPTO_KHAZAD is not set
+# CONFIG_CRYPTO_ANUBIS is not set
+# CONFIG_CRYPTO_DEFLATE is not set
+# CONFIG_CRYPTO_MICHAEL_MIC is not set
+# CONFIG_CRYPTO_CRC32C is not set
+# CONFIG_CRYPTO_CAMELLIA is not set
+# CONFIG_CRYPTO_TEST is not set
+
+#
+# Hardware crypto devices
+#

Re: [0/16] Preliminary Ebony (440GP) support for arch/powerpc

[Josh Boyer]

On Tue, 2007-02-13 at 17:09 +1100, David Gibson wrote:
> Here is a preliminary set of patches implementing support for the
> 440GP based Ebony evaluation board in arch/powerpc.  A number of the
> earlier patches are in Paul's queue already, so may appear in
> powerpc.git at any point.  Most of the later ones need at least some
> cleanup or reworking before they'll be ready for merging.
> 
> With these patches I can boot to a shell prompt on initrd on my Ebony
> board.  There are still a bunch of problems: clock timings are way out
> (runs about 4* fast), things freeze up when I attempt to use an
> nfsroot, many devices aren't supported.  A lot of things are hardcoded
> in the device tree, so you may well have to tweak it if your Ebony is
> different from mine.

I've noticed a couple issues so far on my board, which should just be a
stock Ebony.

1) Things are off when just using the zImage.ebony image.  For reasons
I've yet to narrow down, the bootwrapper thinks something passed an
initrd to it via the a2 parameter in prep_kernel even though there is no
initrd.  I get output like:

Loading file "zImage.ebony" ...                                                 
Sending tftp boot request ...                                                   
Transfer Complete ...                                                           
Loaded successfully ...                                                         
Entry point at 0x400010 ...                                                     
                                                                                
zImage starting: loaded at 0x00400000 (sp: 0x0052bda4)                          
Allocating 0x275088 bytes for kernel ...                                        
Using loader supplied initrd at 0xfff88000 (0x5463007e bytes)                   
gunzipping (0x52c320 <- 0x40a000:0x51e0a4)...done 0x256a94 bytes                
...moving kernel to final address 0x0                                           
                                                                                
Linux/PowerPC load: console=ttyS0                                               
Finalizing device tree... flat tree at 0x4085a0                                 

Which is obviously bogus.  When I ifdef out the check for a2 != 0, it
doesn't try to do the initrd step.

2) I get no boot output after the "Finalizing device tree..." step.  I
don't have a BDI or RW at the moment, but I'll try and figure out where
it's at and what it's doing.

josh

Re: [0/16] Preliminary Ebony (440GP) support for arch/powerpc

[Josh Boyer]

On Tue, 2007-02-13 at 09:46 -0600, Josh Boyer wrote:
> On Tue, 2007-02-13 at 17:09 +1100, David Gibson wrote:
> > Here is a preliminary set of patches implementing support for the
> > 440GP based Ebony evaluation board in arch/powerpc.  A number of the
> > earlier patches are in Paul's queue already, so may appear in
> > powerpc.git at any point.  Most of the later ones need at least some
> > cleanup or reworking before they'll be ready for merging.
> > 
> > With these patches I can boot to a shell prompt on initrd on my Ebony
> > board.  There are still a bunch of problems: clock timings are way out
> > (runs about 4* fast), things freeze up when I attempt to use an
> > nfsroot, many devices aren't supported.  A lot of things are hardcoded
> > in the device tree, so you may well have to tweak it if your Ebony is
> > different from mine.
> 
> I've noticed a couple issues so far on my board, which should just be a
> stock Ebony.
> 
> 1) Things are off when just using the zImage.ebony image.  For reasons
> I've yet to narrow down, the bootwrapper thinks something passed an
> initrd to it via the a2 parameter in prep_kernel even though there is no
> initrd.  I get output like:

I still have this issue, just haven't had a chance to figure out why
yet.  Likely because the openbios code is leaving garbage somewhere.

> 2) I get no boot output after the "Finalizing device tree..." step.  I
> don't have a BDI or RW at the moment, but I'll try and figure out where
> it's at and what it's doing.

After turning on the early debug stuff (once I got it to compile) I get
output of the kernel boot.  Without that enabled however, I get no
kernel boot messages.

josh

Re: [0/16] Preliminary Ebony (440GP) support for arch/powerpc

[David Gibson]

On Wed, Feb 14, 2007 at 10:06:23AM -0600, Josh Boyer wrote:
> On Tue, 2007-02-13 at 09:46 -0600, Josh Boyer wrote:
> > On Tue, 2007-02-13 at 17:09 +1100, David Gibson wrote:
> > > Here is a preliminary set of patches implementing support for the
> > > 440GP based Ebony evaluation board in arch/powerpc.  A number of the
> > > earlier patches are in Paul's queue already, so may appear in
> > > powerpc.git at any point.  Most of the later ones need at least some
> > > cleanup or reworking before they'll be ready for merging.
> > > 
> > > With these patches I can boot to a shell prompt on initrd on my Ebony
> > > board.  There are still a bunch of problems: clock timings are way out
> > > (runs about 4* fast), things freeze up when I attempt to use an
> > > nfsroot, many devices aren't supported.  A lot of things are hardcoded
> > > in the device tree, so you may well have to tweak it if your Ebony is
> > > different from mine.
> > 
> > I've noticed a couple issues so far on my board, which should just be a
> > stock Ebony.
> > 
> > 1) Things are off when just using the zImage.ebony image.  For reasons
> > I've yet to narrow down, the bootwrapper thinks something passed an
> > initrd to it via the a2 parameter in prep_kernel even though there is no
> > initrd.  I get output like:
> 
> I still have this issue, just haven't had a chance to figure out why
> yet.  Likely because the openbios code is leaving garbage somewhere.

More likely simply because openbios just puts different things in the
registers on entry, and we're assuming it uses the same method OF
does.  Need to fix the entry path, and get rid of the hardcoded a1 and
a2 junk.

> > 2) I get no boot output after the "Finalizing device tree..." step.  I
> > don't have a BDI or RW at the moment, but I'll try and figure out where
> > it's at and what it's doing.
> 
> After turning on the early debug stuff (once I got it to compile) I get
> output of the kernel boot.  Without that enabled however, I get no
> kernel boot messages.

Yeah, looks like my stuff for setting up the serial console properly
was bogus, but I didn't notice because I had the udbg console running.

I'm planning to get rid of my hacks to the legacy serial detection,
and instead use Arnd's general OF serial port detection stuff.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [0/16] Preliminary Ebony (440GP) support for arch/powerpc

[Josh Boyer]

On Thu, Feb 15, 2007 at 10:12:04AM +1100, David Gibson wrote:
> > I still have this issue, just haven't had a chance to figure out why
> > yet.  Likely because the openbios code is leaving garbage somewhere.
> 
> More likely simply because openbios just puts different things in the
> registers on entry, and we're assuming it uses the same method OF
> does.  Need to fix the entry path, and get rid of the hardcoded a1 and
> a2 junk.

I looked a the openbios code this morning.  For all intents and purposes
the values it pases in r3 and r4 to the zImage wrapper really are
garbage.  However, you're right in that we need to fix the boot wrapper
to not assume all firmwares will follow similar conventions for the entry
path.

Is there a compat property or something similar that could be defined in
the DTS that the wrapper could look at to determine what to expect?

josh

Re: [0/16] Preliminary Ebony (440GP) support for arch/powerpc

[David Gibson]

On Thu, Feb 15, 2007 at 08:19:56PM -0600, Josh Boyer wrote:
> On Thu, Feb 15, 2007 at 10:12:04AM +1100, David Gibson wrote:
> > > I still have this issue, just haven't had a chance to figure out why
> > > yet.  Likely because the openbios code is leaving garbage somewhere.
> > 
> > More likely simply because openbios just puts different things in the
> > registers on entry, and we're assuming it uses the same method OF
> > does.  Need to fix the entry path, and get rid of the hardcoded a1 and
> > a2 junk.
> 
> I looked a the openbios code this morning.  For all intents and purposes
> the values it pases in r3 and r4 to the zImage wrapper really are
> garbage.  However, you're right in that we need to fix the boot wrapper
> to not assume all firmwares will follow similar conventions for the entry
> path.

Yes.

> Is there a compat property or something similar that could be defined in
> the DTS that the wrapper could look at to determine what to expect?

I think that's getting way too keen on generality.  I'm almost ready
to send out a patch which alters the entry path to the zImage code to
let the platform code handle the entry parameters.  Then we can just
make the Ebony platform_init() ignore the r3 and r4 values.

Err... except, are they really both junk?  I thought at least one gave
an address for the openbios callback to grab the board info structure.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [0/16] Preliminary Ebony (440GP) support for arch/powerpc

[Josh Boyer]

On Fri, Feb 16, 2007 at 01:53:02PM +1100, David Gibson wrote:
> On Thu, Feb 15, 2007 at 08:19:56PM -0600, Josh Boyer wrote:
> > On Thu, Feb 15, 2007 at 10:12:04AM +1100, David Gibson wrote:
> > > > I still have this issue, just haven't had a chance to figure out why
> > > > yet.  Likely because the openbios code is leaving garbage somewhere.
> > > 
> > > More likely simply because openbios just puts different things in the
> > > registers on entry, and we're assuming it uses the same method OF
> > > does.  Need to fix the entry path, and get rid of the hardcoded a1 and
> > > a2 junk.
> > 
> > I looked a the openbios code this morning.  For all intents and purposes
> > the values it pases in r3 and r4 to the zImage wrapper really are
> > garbage.  However, you're right in that we need to fix the boot wrapper
> > to not assume all firmwares will follow similar conventions for the entry
> > path.
> 
> Yes.
> 
> > Is there a compat property or something similar that could be defined in
> > the DTS that the wrapper could look at to determine what to expect?
> 
> I think that's getting way too keen on generality.  I'm almost ready
> to send out a patch which alters the entry path to the zImage code to
> let the platform code handle the entry parameters.  Then we can just
> make the Ebony platform_init() ignore the r3 and r4 values.

Oh good.  I thought about that first, but was afraid of the bootwrapper
generality police ;)

> Err... except, are they really both junk?  I thought at least one gave
> an address for the openbios callback to grab the board info structure.

Not from what I can see.  r3 is used to ensure the data cache is flushed
before jumping to the application, and r4 is used to determine if the
openbios debugger flag is set.  If that flag is set, then control returns
to openbios.  If not, then nothing else is loaded there and it just puts
the entry address of the application in srr0 along with the msr into srr1
and does an rfi.  Neither register is set to something other than that
prior to doing the rfi.

There's also this comment at the top:

"Note that (in the first case) the application is getting
 control for the first time since being loaded, so no
 GPR/SPR values need to be restored (though we do enable
 machine check exceptions in the MSR before returning from
 the interrupt)."

I can look again more closely tomorrow though.  Right now I need to sleep
:)

josh