[0/3] Ebony tweaks

[0/3] Ebony tweaks

[David Gibson]

The core Ebony support is merged now, but here are some extra cleanups
and extensions to the Ebony support.  These are mostly RFC for now,
not expect to merge before 2.6.23.

-- 
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/3] Derive ebc ranges property from EBC registers

[David Gibson]

In the device tree for Ebony, the 'ranges' property in the node for
the EBC bridge shows the mappings from the chip select / address lines
actually used for the EBC peripherals into the address space of the
OPB.  At present, these mappings are hardcoded in ebony.dts for the
mappings set up by the OpenBIOS firmware when it configures the EBC
bridge.

This patch replaces the hardcoded mappings with code in the zImage to
read the EBC configuration registers and create an appropriate ranges
property based on them.  This should make the zImage and kernel more
robust to changes in firmware configuration.  In particular, some of
the Ebony's DIP switches can change the effective address of the Flash
and other peripherals in OPB space.  With this patch, the kernel will
be able to cope with at least some of the possible variations.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---

 arch/powerpc/boot/44x.c         |   29 +++++++++++++++++++++++++++++
 arch/powerpc/boot/44x.h         |    1 +
 arch/powerpc/boot/dcr.h         |   37 +++++++++++++++++++++++++++++++++++++
 arch/powerpc/boot/dts/ebony.dts |    8 +++-----
 arch/powerpc/boot/ebony.c       |    1 +
 5 files changed, 71 insertions(+), 5 deletions(-)

Index: working-2.6/arch/powerpc/boot/dcr.h
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dcr.h	2007-05-14 14:37:57.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dcr.h	2007-05-14 14:45:56.000000000 +1000
@@ -26,6 +26,43 @@ static const unsigned long sdram_bxcr[] 
 #define			SDRAM_CONFIG_BANK_SIZE(reg)	\
 	(0x00400000 << ((reg & SDRAM_CONFIG_SIZE_MASK) >> 17))
 
+/* 440GP External Bus Controller (EBC) */
+#define DCRN_EBC0_CFGADDR				0x012
+#define DCRN_EBC0_CFGDATA				0x013
+#define   EBC_NUM_BANKS					  8
+#define   EBC_B0CR					  0x00
+#define   EBC_B1CR					  0x01
+#define   EBC_B2CR					  0x02
+#define   EBC_B3CR					  0x03
+#define   EBC_B4CR					  0x04
+#define   EBC_B5CR					  0x05
+#define   EBC_B6CR					  0x06
+#define   EBC_B7CR					  0x07
+#define   EBC_BXCR(n)					  (n)
+#define	    EBC_BXCR_BAS				    0xfff00000
+#define	    EBC_BXCR_BS				  	    0x000e0000
+#define	    EBC_BXCR_BANK_SIZE(reg) \
+	(0x100000 << (((reg) & EBC_BXCR_BS) >> 17))
+#define	    EBC_BXCR_BU				  	    0x00018000
+#define	      EBC_BXCR_BU_OFF			  	      0x00000000
+#define	      EBC_BXCR_BU_RO			  	      0x00008000
+#define	      EBC_BXCR_BU_WO			  	      0x00010000
+#define	      EBC_BXCR_BU_RW			  	      0x00018000
+#define	    EBC_BXCR_BW				  	    0x00006000
+#define   EBC_B0AP					  0x10
+#define   EBC_B1AP					  0x11
+#define   EBC_B2AP					  0x12
+#define   EBC_B3AP					  0x13
+#define   EBC_B4AP					  0x14
+#define   EBC_B5AP					  0x15
+#define   EBC_B6AP					  0x16
+#define   EBC_B7AP					  0x17
+#define   EBC_BXAP(n)					  (0x10+(n))
+#define   EBC_BEAR					  0x20
+#define   EBC_BESR					  0x21
+#define   EBC_CFG					  0x23
+#define   EBC_CID					  0x24
+
 /* 440GP Clock, PM, chip control */
 #define DCRN_CPC0_SR					0x0b0
 #define DCRN_CPC0_ER					0x0b1
Index: working-2.6/arch/powerpc/boot/ebony.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/ebony.c	2007-05-14 14:45:55.000000000 +1000
+++ working-2.6/arch/powerpc/boot/ebony.c	2007-05-14 14:45:56.000000000 +1000
@@ -100,6 +100,7 @@ static void ebony_fixups(void)
 	ibm440gp_fixup_clocks(sysclk, 6 * 1843200);
 	ibm44x_fixup_memsize();
 	dt_fixup_mac_addresses(ebony_mac0, ebony_mac1);
+	ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
 }
 
 void ebony_init(void *mac0, void *mac1)
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:38:39.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:45:56.000000000 +1000
@@ -136,11 +136,9 @@
 				#address-cells = <2>;
 				#size-cells = <1>;
 				clock-frequency = <0>; // Filled in by zImage
-				ranges = <0 00000000 fff00000 100000
-					  1 00000000 48000000 100000
-					  2 00000000 ff800000 400000
-					  3 00000000 48200000 100000
-					  7 00000000 48300000 100000>;
+				// ranges property is supplied by zImage
+				// based on firmware's configuration of the
+				// EBC bridge
 				interrupts = <5 4>;
 				interrupt-parent = <&UIC1>;
 
Index: working-2.6/arch/powerpc/boot/44x.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/44x.c	2007-05-14 14:45:55.000000000 +1000
+++ working-2.6/arch/powerpc/boot/44x.c	2007-05-14 14:45:56.000000000 +1000
@@ -54,3 +54,32 @@ void ibm44x_dbcr_reset(void)
 		);
 
 }
+
+/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
+ * banks into the OPB address space */
+void ibm4xx_fixup_ebc_ranges(const char *ebc)
+{
+	void *devp;
+	u32 bxcr;
+	u32 ranges[EBC_NUM_BANKS*4];
+	u32 *p = ranges;
+	int i;
+
+	for (i = 0; i < EBC_NUM_BANKS; i++) {
+		mtdcr(DCRN_EBC0_CFGADDR, EBC_BXCR(i));
+		bxcr = mfdcr(DCRN_EBC0_CFGDATA);
+
+		if ((bxcr & EBC_BXCR_BU) != EBC_BXCR_BU_OFF) {
+			*p++ = i;
+			*p++ = 0;
+			*p++ = bxcr & EBC_BXCR_BAS;
+			*p++ = EBC_BXCR_BANK_SIZE(bxcr);
+		}
+	}
+
+	devp = finddevice(ebc);
+	if (! devp)
+		fatal("Couldn't locate EBC node %s\n\r", ebc);
+
+	setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
+}
Index: working-2.6/arch/powerpc/boot/44x.h
===================================================================
--- working-2.6.orig/arch/powerpc/boot/44x.h	2007-05-14 14:45:55.000000000 +1000
+++ working-2.6/arch/powerpc/boot/44x.h	2007-05-14 14:45:56.000000000 +1000
@@ -11,6 +11,7 @@
 #define _PPC_BOOT_44X_H_
 
 void ibm44x_fixup_memsize(void);
+void ibm4xx_fixup_ebc_ranges(const char *ebc);
 
 void ibm44x_dbcr_reset(void);
 void ebony_init(void *mac0, void *mac1);

Re: [PATCH 2/3] Derive ebc ranges property from EBC registers

[Josh Boyer]

On Tue, 2007-05-15 at 14:54 +1000, David Gibson wrote:
>  void ebony_init(void *mac0, void *mac1)
> Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:38:39.000000000 +1000
> +++ working-2.6/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:45:56.000000000 +1000
> @@ -136,11 +136,9 @@
>  				#address-cells = <2>;
>  				#size-cells = <1>;
>  				clock-frequency = <0>; // Filled in by zImage
> -				ranges = <0 00000000 fff00000 100000
> -					  1 00000000 48000000 100000
> -					  2 00000000 ff800000 400000
> -					  3 00000000 48200000 100000
> -					  7 00000000 48300000 100000>;
> +				// ranges property is supplied by zImage
> +				// based on firmware's configuration of the
> +				// EBC bridge

Do we want a "ranges;" here as a placeholder?  I don't see where it's
absolutely required, but it makes me feel better for some reason...

> +
> +/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
> + * banks into the OPB address space */
> +void ibm4xx_fixup_ebc_ranges(const char *ebc)
> +{
> +	void *devp;
> +	u32 bxcr;
> +	u32 ranges[EBC_NUM_BANKS*4];
> +	u32 *p = ranges;
> +	int i;
> +
> +	for (i = 0; i < EBC_NUM_BANKS; i++) {
> +		mtdcr(DCRN_EBC0_CFGADDR, EBC_BXCR(i));
> +		bxcr = mfdcr(DCRN_EBC0_CFGDATA);
> +
> +		if ((bxcr & EBC_BXCR_BU) != EBC_BXCR_BU_OFF) {
> +			*p++ = i;
> +			*p++ = 0;
> +			*p++ = bxcr & EBC_BXCR_BAS;
> +			*p++ = EBC_BXCR_BANK_SIZE(bxcr);
> +		}
> +	}
> +
> +	devp = finddevice(ebc);
> +	if (! devp)
> +		fatal("Couldn't locate EBC node %s\n\r", ebc);
> +
> +	setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
> +}

So this sets the ranges for the EBC bus, but not the "regs" properties
of the child nodes.  Without that, the child nodes will not be mapped to
the correct addresses...

Did you have a plan on how to fixup the child "regs" properties so that
when the DIP switches are flipped around, the children show up
correctly?

josh

Re: [PATCH 2/3] Derive ebc ranges property from EBC registers

[David Gibson]

On Tue, May 15, 2007 at 07:59:58AM -0500, Josh Boyer wrote:
> On Tue, 2007-05-15 at 14:54 +1000, David Gibson wrote:
> >  void ebony_init(void *mac0, void *mac1)
> > Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> > ===================================================================
> > --- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:38:39.000000000 +1000
> > +++ working-2.6/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:45:56.000000000 +1000
> > @@ -136,11 +136,9 @@
> >  				#address-cells = <2>;
> >  				#size-cells = <1>;
> >  				clock-frequency = <0>; // Filled in by zImage
> > -				ranges = <0 00000000 fff00000 100000
> > -					  1 00000000 48000000 100000
> > -					  2 00000000 ff800000 400000
> > -					  3 00000000 48200000 100000
> > -					  7 00000000 48300000 100000>;
> > +				// ranges property is supplied by zImage
> > +				// based on firmware's configuration of the
> > +				// EBC bridge
> 
> Do we want a "ranges;" here as a placeholder?  I don't see where it's
> absolutely required, but it makes me feel better for some reason...

Absolutely not.  An empty ranges property indicates that the child bus
address space is the same as the parent bus address space.  If we're
using the chip-select/offset addressing form for the EBC peripherals,
that's manifestly not the case.

> > +
> > +/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
> > + * banks into the OPB address space */
> > +void ibm4xx_fixup_ebc_ranges(const char *ebc)
> > +{
> > +	void *devp;
> > +	u32 bxcr;
> > +	u32 ranges[EBC_NUM_BANKS*4];
> > +	u32 *p = ranges;
> > +	int i;
> > +
> > +	for (i = 0; i < EBC_NUM_BANKS; i++) {
> > +		mtdcr(DCRN_EBC0_CFGADDR, EBC_BXCR(i));
> > +		bxcr = mfdcr(DCRN_EBC0_CFGDATA);
> > +
> > +		if ((bxcr & EBC_BXCR_BU) != EBC_BXCR_BU_OFF) {
> > +			*p++ = i;
> > +			*p++ = 0;
> > +			*p++ = bxcr & EBC_BXCR_BAS;
> > +			*p++ = EBC_BXCR_BANK_SIZE(bxcr);
> > +		}
> > +	}
> > +
> > +	devp = finddevice(ebc);
> > +	if (! devp)
> > +		fatal("Couldn't locate EBC node %s\n\r", ebc);
> > +
> > +	setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
> > +}
> 
> So this sets the ranges for the EBC bus, but not the "regs" properties
> of the child nodes.  Without that, the child nodes will not be mapped to
> the correct addresses...

Well, no, the child reg properties can't be deduced from the EBC
registers.

> Did you have a plan on how to fixup the child "regs" properties so that
> when the DIP switches are flipped around, the children show up
> correctly?

Well, on Ebony (AFAICT), the only child reg property that might need
adjustment is the small flash.  My MTD enabling patch includes some
code in the boot wrapper to toggle the appropriate bit in it's reg
property.

-- 
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 2/3] Derive ebc ranges property from EBC registers

[Josh Boyer]

On Wed, May 16, 2007 at 09:09:30AM +1000, David Gibson wrote:
> > Do we want a "ranges;" here as a placeholder?  I don't see where it's
> > absolutely required, but it makes me feel better for some reason...
> 
> Absolutely not.  An empty ranges property indicates that the child bus
> address space is the same as the parent bus address space.  If we're
> using the chip-select/offset addressing form for the EBC peripherals,
> that's manifestly not the case.

Ah ok.  My lack of device tree experience showing through again.

> > So this sets the ranges for the EBC bus, but not the "regs" properties
> > of the child nodes.  Without that, the child nodes will not be mapped to
> > the correct addresses...
> 
> Well, no, the child reg properties can't be deduced from the EBC
> registers.

Right, I didn't mean to imply the could be.

> > Did you have a plan on how to fixup the child "regs" properties so that
> > when the DIP switches are flipped around, the children show up
> > correctly?
> 
> Well, on Ebony (AFAICT), the only child reg property that might need
> adjustment is the small flash.  My MTD enabling patch includes some
> code in the boot wrapper to toggle the appropriate bit in it's reg
> property.

Hm, ok.  On Bamboo, it's more complicated.  I'll have to think of something
there I suppose.

josh

Re: [PATCH 2/3] Derive ebc ranges property from EBC registers

[David Gibson]

On Tue, May 15, 2007 at 09:29:59PM -0500, Josh Boyer wrote:
> On Wed, May 16, 2007 at 09:09:30AM +1000, David Gibson wrote:
> > > Do we want a "ranges;" here as a placeholder?  I don't see where it's
> > > absolutely required, but it makes me feel better for some reason...
> > 
> > Absolutely not.  An empty ranges property indicates that the child bus
> > address space is the same as the parent bus address space.  If we're
> > using the chip-select/offset addressing form for the EBC peripherals,
> > that's manifestly not the case.
> 
> Ah ok.  My lack of device tree experience showing through again.
> 
> > > So this sets the ranges for the EBC bus, but not the "regs" properties
> > > of the child nodes.  Without that, the child nodes will not be mapped to
> > > the correct addresses...
> > 
> > Well, no, the child reg properties can't be deduced from the EBC
> > registers.
> 
> Right, I didn't mean to imply the could be.
> 
> > > Did you have a plan on how to fixup the child "regs" properties so that
> > > when the DIP switches are flipped around, the children show up
> > > correctly?
> > 
> > Well, on Ebony (AFAICT), the only child reg property that might need
> > adjustment is the small flash.  My MTD enabling patch includes some
> > code in the boot wrapper to toggle the appropriate bit in it's reg
> > property.
> 
> Hm, ok.  On Bamboo, it's more complicated.  I'll have to think of something
> there I suppose.

Want to send me a board manual?  I can see if any approach springs to
mind.

-- 
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 2/3] Derive ebc ranges property from EBC registers

[Segher Boessenkool]

>> Do we want a "ranges;" here as a placeholder?  I don't see where it's
>> absolutely required, but it makes me feel better for some reason...
>
> Absolutely not.  An empty ranges property indicates that the child bus
> address space is the same as the parent bus address space.

Or a subset of it, anyway; both address domains have to
use the same representation in "reg" properties, and the
mapping has to be 1-1.

A missing "ranges" property means there is no direct
mapping, which is more correct in this case, and perfectly
valid.

> If we're
> using the chip-select/offset addressing form for the EBC peripherals,
> that's manifestly not the case.

This would be a nice use case for the

	ranges = ??;

syntax when/if that gets added to DTC and the kernel
and bootwrapper parsers for DTBs.


Segher

[PATCH 1/3] Factor zImage's 44x reset code out of ebony.c

[David Gibson]

The ebony_exit() function which resets the Ebony board should in fact
be common to most if not all 44x boards.  This patch moves the
function out into 44x.c, renaming it, so it can be used by other 44x
platforms.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---

 arch/powerpc/boot/44x.c   |   16 ++++++++++++++++
 arch/powerpc/boot/44x.h   |    2 ++
 arch/powerpc/boot/ebony.c |   18 +-----------------
 3 files changed, 19 insertions(+), 17 deletions(-)

Index: working-2.6/arch/powerpc/boot/44x.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/44x.c	2007-05-08 15:07:45.000000000 +1000
+++ working-2.6/arch/powerpc/boot/44x.c	2007-05-14 13:15:22.000000000 +1000
@@ -38,3 +38,19 @@ void ibm44x_fixup_memsize(void)
 
 	dt_fixup_memory(0, memsize);
 }
+
+#define SPRN_DBCR0		0x134
+#define   DBCR0_RST_SYSTEM	0x30000000
+
+void ibm44x_dbcr_reset(void)
+{
+	unsigned long tmp;
+
+	asm volatile (
+		"mfspr	%0,%1\n"
+		"oris	%0,%0,%2@h\n"
+		"mtspr	%1,%0"
+		: "=&r"(tmp) : "i"(SPRN_DBCR0), "i"(DBCR0_RST_SYSTEM)
+		);
+
+}
Index: working-2.6/arch/powerpc/boot/44x.h
===================================================================
--- working-2.6.orig/arch/powerpc/boot/44x.h	2007-05-08 15:07:45.000000000 +1000
+++ working-2.6/arch/powerpc/boot/44x.h	2007-05-14 13:15:52.000000000 +1000
@@ -11,6 +11,8 @@
 #define _PPC_BOOT_44X_H_
 
 void ibm44x_fixup_memsize(void);
+
+void ibm44x_dbcr_reset(void);
 void ebony_init(void *mac0, void *mac1);
 
 #endif /* _PPC_BOOT_44X_H_ */
Index: working-2.6/arch/powerpc/boot/ebony.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/ebony.c	2007-05-08 15:07:45.000000000 +1000
+++ working-2.6/arch/powerpc/boot/ebony.c	2007-05-14 13:15:22.000000000 +1000
@@ -102,26 +102,10 @@ static void ebony_fixups(void)
 	dt_fixup_mac_addresses(ebony_mac0, ebony_mac1);
 }
 
-#define SPRN_DBCR0		0x134
-#define   DBCR0_RST_SYSTEM	0x30000000
-
-static void ebony_exit(void)
-{
-	unsigned long tmp;
-
-	asm volatile (
-		"mfspr	%0,%1\n"
-		"oris	%0,%0,%2@h\n"
-		"mtspr	%1,%0"
-		: "=&r"(tmp) : "i"(SPRN_DBCR0), "i"(DBCR0_RST_SYSTEM)
-		);
-
-}
-
 void ebony_init(void *mac0, void *mac1)
 {
 	platform_ops.fixups = ebony_fixups;
-	platform_ops.exit = ebony_exit;
+	platform_ops.exit = ibm44x_dbcr_reset;
 	ebony_mac0 = mac0;
 	ebony_mac1 = mac1;
 	ft_init(_dtb_start, _dtb_end - _dtb_start, 32);

Re: [PATCH 1/3] Factor zImage's 44x reset code out of ebony.c

[Josh Boyer]

On Tue, 2007-05-15 at 14:54 +1000, David Gibson wrote:
> The ebony_exit() function which resets the Ebony board should in fact
> be common to most if not all 44x boards.  This patch moves the
> function out into 44x.c, renaming it, so it can be used by other 44x
> platforms.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Tested on my ebony board.  Will work nicely for 440EP as well.

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

[PATCH 3/3] Fixes to allow use of Ebony's flash chips through physmap_of

[David Gibson]

This patch contains a handful of small fixes to allow the Ebony's
flash to be exposed as MTD devices via the physmap_of driver.
Specifically it:
	- Makes a small addition to the device tree and zImage wrapper
to record the correct address for the flash in the device tree based
on the board switches as reported via an FPGA register.
	- Prohibits building the old hard-coded "Ebony" flash map on
arch/powerpc kernels, in favour of using physmap_of's device tree
based approach.
	- Enables MTD and physmap_of in the Ebony defconfig.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---

 arch/powerpc/boot/dts/ebony.dts      |    1 
 arch/powerpc/boot/ebony.c            |   41 +++++++++
 arch/powerpc/configs/ebony_defconfig |  148 ++++++++++++++++++++++++++---------
 drivers/mtd/maps/Kconfig             |    2 
 4 files changed, 154 insertions(+), 38 deletions(-)

Index: working-2.6/drivers/mtd/maps/Kconfig
===================================================================
--- working-2.6.orig/drivers/mtd/maps/Kconfig	2007-05-14 14:37:57.000000000 +1000
+++ working-2.6/drivers/mtd/maps/Kconfig	2007-05-14 14:45:58.000000000 +1000
@@ -368,7 +368,7 @@ config MTD_WALNUT
 
 config MTD_EBONY
 	tristate "Flash devices mapped on IBM 440GP Ebony"
-	depends on MTD_JEDECPROBE && EBONY
+	depends on MTD_JEDECPROBE && EBONY && !PPC_MERGE
 	help
 	  This enables access routines for the flash chips on the IBM 440GP
 	  Ebony board. If you have one of these boards and would like to
Index: working-2.6/arch/powerpc/configs/ebony_defconfig
===================================================================
--- working-2.6.orig/arch/powerpc/configs/ebony_defconfig	2007-05-14 14:37:57.000000000 +1000
+++ working-2.6/arch/powerpc/configs/ebony_defconfig	2007-05-14 14:45:58.000000000 +1000
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.21
-# Fri May  4 13:47:08 2007
+# Linux kernel version: 2.6.21-powerpc-ebony-mtd
+# Fri May 11 14:41:46 2007
 #
 # CONFIG_PPC64 is not set
 CONFIG_PPC32=y
@@ -45,6 +45,7 @@ CONFIG_4xx=y
 CONFIG_BOOKE=y
 CONFIG_PTE_64BIT=y
 CONFIG_PHYS_64BIT=y
+# CONFIG_PPC_MM_SLICES is not set
 CONFIG_NOT_COHERENT_CACHE=y
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
 
@@ -70,6 +71,7 @@ CONFIG_POSIX_MQUEUE=y
 # CONFIG_UTS_NS is not set
 # CONFIG_AUDIT is not set
 # CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
 CONFIG_SYSFS_DEPRECATED=y
 # CONFIG_RELAY is not set
 CONFIG_BLK_DEV_INITRD=y
@@ -89,12 +91,13 @@ CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_EPOLL=y
 CONFIG_SHMEM=y
-CONFIG_SLAB=y
 CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_SLAB=y
+# CONFIG_SLUB is not set
+# CONFIG_SLOB is not set
 CONFIG_RT_MUTEXES=y
 # CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
-# CONFIG_SLOB is not set
 
 #
 # Loadable module support
@@ -193,16 +196,14 @@ CONFIG_PPC_INDIRECT_PCI=y
 CONFIG_PCI=y
 CONFIG_PCI_DOMAINS=y
 # CONFIG_PCIEPORTBUS is not set
+CONFIG_ARCH_SUPPORTS_MSI=y
+# CONFIG_PCI_MSI 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
 
 #
@@ -310,7 +311,9 @@ CONFIG_DEFAULT_TCP_CONG="cubic"
 #
 # CONFIG_CFG80211 is not set
 # CONFIG_WIRELESS_EXT is not set
+# CONFIG_MAC80211 is not set
 # CONFIG_IEEE80211 is not set
+# CONFIG_RFKILL is not set
 
 #
 # Device Drivers
@@ -331,7 +334,80 @@ CONFIG_FW_LOADER=y
 #
 CONFIG_CONNECTOR=y
 CONFIG_PROC_EVENTS=y
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+# CONFIG_MTD_CMDLINE_PARTS is not set
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+CONFIG_MTD_JEDECPROBE=y
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
 
 #
 # Parallel port support
@@ -365,8 +441,10 @@ CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
 #
 # Misc devices
 #
+# CONFIG_PHANTOM is not set
 # CONFIG_SGI_IOC4 is not set
 # CONFIG_TIFM_CORE is not set
+# CONFIG_BLINK is not set
 
 #
 # ATA/ATAPI/MFM/RLL support
@@ -398,6 +476,7 @@ CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
 #
 # IEEE 1394 (FireWire) support
 #
+# CONFIG_FIREWIRE is not set
 # CONFIG_IEEE1394 is not set
 
 #
@@ -468,6 +547,8 @@ CONFIG_IBM_NEW_EMAC_ZMII=y
 # CONFIG_S2IO is not set
 # CONFIG_MYRI10GE is not set
 # CONFIG_NETXEN_NIC is not set
+# CONFIG_MLX4_CORE is not set
+CONFIG_MLX4_DEBUG=y
 
 #
 # Token Ring devices
@@ -550,15 +631,10 @@ CONFIG_LEGACY_PTY_COUNT=256
 # IPMI
 #
 # CONFIG_IPMI_HANDLER is not set
-
-#
-# Watchdog Cards
-#
 # CONFIG_WATCHDOG is not set
 # CONFIG_HW_RANDOM is not set
 # 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
@@ -569,10 +645,7 @@ CONFIG_LEGACY_PTY_COUNT=256
 # TPM devices
 #
 # CONFIG_TCG_TPM is not set
-
-#
-# I2C support
-#
+CONFIG_DEVPORT=y
 # CONFIG_I2C is not set
 
 #
@@ -585,12 +658,7 @@ CONFIG_LEGACY_PTY_COUNT=256
 # Dallas's 1-wire bus
 #
 # CONFIG_W1 is not set
-
-#
-# Hardware Monitoring support
-#
 # CONFIG_HWMON is not set
-# CONFIG_HWMON_VID is not set
 
 #
 # Multifunction device drivers
@@ -611,6 +679,12 @@ CONFIG_LEGACY_PTY_COUNT=256
 # Graphics support
 #
 # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+
+#
+# Display device support
+#
+# CONFIG_DISPLAY_SUPPORT is not set
+# CONFIG_VGASTATE is not set
 # CONFIG_FB is not set
 # CONFIG_FB_IBM_GXT4500 is not set
 
@@ -635,10 +709,6 @@ CONFIG_USB_ARCH_HAS_EHCI=y
 # USB Gadget Support
 #
 # CONFIG_USB_GADGET is not set
-
-#
-# MMC/SD Card support
-#
 # CONFIG_MMC is not set
 
 #
@@ -682,14 +752,6 @@ CONFIG_USB_ARCH_HAS_EHCI=y
 #
 
 #
-# Auxiliary Display support
-#
-
-#
-# Virtualization
-#
-
-#
 # File systems
 #
 CONFIG_EXT2_FS=y
@@ -749,6 +811,15 @@ CONFIG_RAMFS=y
 # CONFIG_BEFS_FS is not set
 # CONFIG_BFS_FS is not set
 # CONFIG_EFS_FS is not set
+CONFIG_JFFS2_FS=y
+CONFIG_JFFS2_FS_DEBUG=0
+CONFIG_JFFS2_FS_WRITEBUFFER=y
+# CONFIG_JFFS2_SUMMARY is not set
+# CONFIG_JFFS2_FS_XATTR is not set
+# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
+CONFIG_JFFS2_ZLIB=y
+CONFIG_JFFS2_RTIME=y
+# CONFIG_JFFS2_RUBIN is not set
 CONFIG_CRAMFS=y
 # CONFIG_VXFS_FS is not set
 # CONFIG_HPFS_FS is not set
@@ -770,6 +841,7 @@ CONFIG_LOCKD=y
 CONFIG_LOCKD_V4=y
 CONFIG_NFS_COMMON=y
 CONFIG_SUNRPC=y
+# CONFIG_SUNRPC_BIND34 is not set
 # CONFIG_RPCSEC_GSS_KRB5 is not set
 # CONFIG_RPCSEC_GSS_SPKM3 is not set
 # CONFIG_SMB_FS is not set
@@ -803,12 +875,15 @@ CONFIG_MSDOS_PARTITION=y
 CONFIG_BITREVERSE=y
 # CONFIG_CRC_CCITT is not set
 # CONFIG_CRC16 is not set
+# CONFIG_CRC_ITU_T is not set
 CONFIG_CRC32=y
 # CONFIG_LIBCRC32C is not set
 CONFIG_ZLIB_INFLATE=y
+CONFIG_ZLIB_DEFLATE=y
 CONFIG_PLIST=y
 CONFIG_HAS_IOMEM=y
 CONFIG_HAS_IOPORT=y
+CONFIG_HAS_DMA=y
 
 #
 # Instrumentation Support
@@ -826,7 +901,6 @@ CONFIG_MAGIC_SYSRQ=y
 # 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_TIMER_STATS is not set
@@ -851,7 +925,6 @@ CONFIG_FORCED_INLINING=y
 # CONFIG_DEBUGGER is not set
 # CONFIG_BDI_SWITCH is not set
 # CONFIG_BOOTX_TEXT is not set
-# CONFIG_SERIAL_TEXT_DEBUG is not set
 # CONFIG_PPC_EARLY_DEBUG is not set
 
 #
@@ -882,6 +955,7 @@ CONFIG_CRYPTO_ECB=y
 CONFIG_CRYPTO_CBC=y
 CONFIG_CRYPTO_PCBC=y
 # CONFIG_CRYPTO_LRW is not set
+# CONFIG_CRYPTO_CRYPTD is not set
 CONFIG_CRYPTO_DES=y
 # CONFIG_CRYPTO_FCRYPT is not set
 # CONFIG_CRYPTO_BLOWFISH is not set
Index: working-2.6/arch/powerpc/boot/ebony.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/ebony.c	2007-05-14 14:45:56.000000000 +1000
+++ working-2.6/arch/powerpc/boot/ebony.c	2007-05-14 14:45:58.000000000 +1000
@@ -24,6 +24,7 @@
 #include "page.h"
 #include "ops.h"
 #include "reg.h"
+#include "io.h"
 #include "dcr.h"
 #include "44x.h"
 
@@ -92,6 +93,45 @@ void ibm440gp_fixup_clocks(unsigned int 
 	dt_fixup_clock("/plb/opb/serial@40000300", uart1);
 }
 
+#define EBONY_FPGA_PATH		"/plb/opb/ebc/fpga"
+#define	EBONY_FPGA_FLASH_SEL	0x01
+#define EBONY_SMALL_FLASH_PATH	"/plb/opb/ebc/small-flash"
+
+static void ebony_flashsel_fixup(void)
+{
+	void *devp;
+	u32 reg[3] = {0x0, 0x0, 0x80000};
+	u8 *fpga;
+	u8 fpga_reg0 = 0x0;
+
+	devp = finddevice(EBONY_FPGA_PATH);
+	if (! devp)
+		fatal("Couldn't locate FPGA node %s\n\r", EBONY_FPGA_PATH);
+
+	if (getprop(devp, "virtual-reg", fpga, sizeof(fpga)) != sizeof(fpga))
+		fatal("%s has virtual-reg property of unexpected size\n\r",
+		      EBONY_FPGA_PATH);
+
+	fpga_reg0 = in_8(fpga);
+
+	printf("Ebony: FPGA register 0 = 0x%02x\n\r", fpga_reg0);
+
+	devp = finddevice(EBONY_SMALL_FLASH_PATH);
+	if (! devp)
+		fatal("Couldn't locate small flash node %s\n\r",
+		      EBONY_SMALL_FLASH_PATH);
+
+	if (getprop(devp, "reg", reg, sizeof(reg)) != sizeof(reg))
+		fatal("%s has reg property of unexpected size\n\r",
+		      EBONY_SMALL_FLASH_PATH);
+
+	/* Invert address bit 14 (IBM-endian) if FLASH_SEL fpga bit is set */
+	if (fpga_reg0 & EBONY_FPGA_FLASH_SEL)
+		reg[1] ^= 0x80000;
+
+	setprop(devp, "reg", reg, sizeof(reg));
+}
+
 static void ebony_fixups(void)
 {
 	// FIXME: sysclk should be derived by reading the FPGA registers
@@ -101,6 +141,7 @@ static void ebony_fixups(void)
 	ibm44x_fixup_memsize();
 	dt_fixup_mac_addresses(ebony_mac0, ebony_mac1);
 	ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
+	ebony_flashsel_fixup();
 }
 
 void ebony_init(void *mac0, void *mac1)
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:45:56.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:45:58.000000000 +1000
@@ -176,6 +176,7 @@
 				fpga@7,0 {
 					compatible = "Ebony-FPGA";
 					reg = <7 0 10>;
+					virtual-reg = <e8300000>;
 				};
 			};
 

Re: [PATCH 3/3] Fixes to allow use of Ebony's flash chips through physmap_of

[Josh Boyer]

On Tue, 2007-05-15 at 14:54 +1000, David Gibson wrote:
>  void ebony_init(void *mac0, void *mac1)
> Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:45:56.000000000 +1000
> +++ working-2.6/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:45:58.000000000 +1000
> @@ -176,6 +176,7 @@
>  				fpga@7,0 {
>  					compatible = "Ebony-FPGA";
>  					reg = <7 0 10>;
> +					virtual-reg = <e8300000>;

That's the mapping for OpenBios.  What happens if someone is using
U-Boot?

If the mapping isn't the same, you might want to pass the address from
the individual firmware wrapper parts to ebony_flashsel_fixup similar to
how you've done it for dt_fixup_mac_addresses.

josh

Re: [PATCH 3/3] Fixes to allow use of Ebony's flash chips through physmap_of

[David Gibson]

On Tue, May 15, 2007 at 08:10:06AM -0500, Josh Boyer wrote:
> On Tue, 2007-05-15 at 14:54 +1000, David Gibson wrote:
> >  void ebony_init(void *mac0, void *mac1)
> > Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> > ===================================================================
> > --- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:45:56.000000000 +1000
> > +++ working-2.6/arch/powerpc/boot/dts/ebony.dts	2007-05-14 14:45:58.000000000 +1000
> > @@ -176,6 +176,7 @@
> >  				fpga@7,0 {
> >  					compatible = "Ebony-FPGA";
> >  					reg = <7 0 10>;
> > +					virtual-reg = <e8300000>;
> 
> That's the mapping for OpenBios.  What happens if someone is using
> U-Boot?

I think U-Boot uses the same default IO mappings.

> If the mapping isn't the same, you might want to pass the address from
> the individual firmware wrapper parts to ebony_flashsel_fixup similar to
> how you've done it for dt_fixup_mac_addresses.
> 
> josh
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 

-- 
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