Skip to contentSkip to conversation

Ebony tweaks

PATCH In review David Gibson 4 participants 12 messages May 15, 2007 – May 16, 2007

Subsystems (3)
Device tree bindings PowerPC Memory technology devices (MTD)
lore
Share & tools
lore

David Gibson

author
#0 lore raw

cover Ebony tweaks

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.

Signature · 4 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
author
#1 lore raw

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

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 <[email protected]>

---

 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(-)
arch/powerpc/boot/44x.c +16 -0
Index: working-2.6/arch/powerpc/boot/44x.c
===================================================================
@@ -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)
+		);
+
+}
arch/powerpc/boot/44x.h +2 -0
Index: working-2.6/arch/powerpc/boot/44x.h
===================================================================
@@ -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_ */
arch/powerpc/boot/ebony.c +1 -17
Index: working-2.6/arch/powerpc/boot/ebony.c
===================================================================
@@ -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);
Acked-by on v1 1/3
#2 lore raw

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

Quoted 6 lines · 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 <[email protected]>

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

Acked-by Josh Boyer <[email protected]>
author
#3 lore raw

PATCH 2/3 Derive ebc ranges property from EBC registers

In reply to 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 <[email protected]>

---

 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(-)
arch/powerpc/boot/dcr.h +37 -0
Index: working-2.6/arch/powerpc/boot/dcr.h
===================================================================
@@ -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
arch/powerpc/boot/ebony.c +1 -0
Index: working-2.6/arch/powerpc/boot/ebony.c
===================================================================
@@ -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)
arch/powerpc/boot/dts/ebony.dts +3 -5
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
@@ -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>;
arch/powerpc/boot/44x.c +29 -0
Index: working-2.6/arch/powerpc/boot/44x.c
===================================================================
@@ -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));
+}
arch/powerpc/boot/44x.h +1 -0
Index: working-2.6/arch/powerpc/boot/44x.h
===================================================================
@@ -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);
#4 lore raw

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

Quoted 7 lines · David Gibson

void ebony_init(void *mac0, void *mac1)
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================

arch/powerpc/boot/dts/ebony.dts +0 -0
@@ -136,11 +136,9 @@
 				#address-cells = <2>;

arch/powerpc/boot/dts/ebony.dts line 141

Quoted 10 lines
arch/powerpc/boot/dts/ebony.dts +3 -5
 				#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...

Quoted 19 lines
arch/powerpc/boot/dts/ebony.dts +19 -0
+
+/* 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;

arch/powerpc/boot/dts/ebony.dts

Quoted 10 lines
arch/powerpc/boot/dts/ebony.dts +10 -0
+			*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

#5 lore raw

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

Quoted 13 lines · Josh Boyer
Quoted 12 lines · David Gibson

void ebony_init(void *mac0, void *mac1)
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================

arch/powerpc/boot/dts/ebony.dts +0 -3
@@ -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
Quoted 8 lines

arch/powerpc/boot/dts/ebony.dts line 141

Quoted 5 lines
arch/powerpc/boot/dts/ebony.dts +3 -2
-					  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.

Quoted 25 lines
Quoted 25 lines
arch/powerpc/boot/dts/ebony.dts +25 -0
+
+/* 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)
Quoted 8 lines

arch/powerpc/boot/dts/ebony.dts

Quoted 4 lines
arch/powerpc/boot/dts/ebony.dts +4 -0
+		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.

Quoted 3 lines

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.

Signature · 4 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
#6 lore raw

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

Quoted 7 lines · David Gibson
Quoted 2 lines

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.

Quoted 6 lines
Quoted 3 lines

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.

Quoted 8 lines
Quoted 3 lines

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

#7 lore raw

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

Quoted 24 lines · Josh Boyer
Quoted 7 lines · David Gibson
Quoted 2 lines

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.

Quoted 6 lines
Quoted 3 lines

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.

Quoted 4 lines
Quoted 3 lines

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?

Quoted 7 lines
Quoted 4 lines

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.

Signature · 4 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
#8 lore raw

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

In reply to David Gibson
Quoted 5 lines
Quoted 2 lines

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.

Quoted 3 lines

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

author
#9 lore raw

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

In reply to 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 <[email protected]>

---

 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(-)
drivers/mtd/maps/Kconfig +1 -1
Index: working-2.6/drivers/mtd/maps/Kconfig
===================================================================
@@ -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
arch/powerpc/configs/ebony_defconfig +111 -37

303 lines not on this page · raw message

arch/powerpc/boot/ebony.c +41 -0

59 lines not on this page · raw message

arch/powerpc/boot/dts/ebony.dts +1 -0
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
@@ -176,6 +176,7 @@
 				fpga@7,0 {
 					compatible = "Ebony-FPGA";
 					reg = <7 0 10>;
+					virtual-reg = <e8300000>;
 				};
 			};
#10 lore raw

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

arch/powerpc/boot/dts/ebony.dts line 179

Quoted 10 lines · David Gibson

void ebony_init(void *mac0, void *mac1)
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================

arch/powerpc/boot/dts/ebony.dts +1 -0
@@ -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

#11 lore raw

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

Quoted 14 lines · Josh Boyer

arch/powerpc/boot/dts/ebony.dts line 179

Quoted 10 lines · David Gibson

void ebony_init(void *mac0, void *mac1)
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================

arch/powerpc/boot/dts/ebony.dts +1 -0
@@ -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.

Quoted 11 lines

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
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Signature · 4 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