ARM: Kirkwood: Add support for Excito Bubba B3

The Excito Bubba B3 is a home server, single driver NAS box, Wifi

access point, etc.

Signed-off-by Andrew Lunn <[email protected]>

---
 arch/arm/boot/dts/Makefile        |    3 +-
 arch/arm/boot/dts/kirkwood-b3.dts |  199 +++++++++++++++++++++++++++++++++++++
 2 files changed, 201 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-b3.dts

arch/arm/boot/dts/Makefile +2 -1

index adcc6067eb13..0447d726a6bc 100644
@@ -71,7 +71,8 @@ dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
 dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
 	integratorcp.dtb
 dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
-dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-b3.dtb \
+	kirkwood-cloudbox.dtb \
 	kirkwood-db-88f6281.dtb \
 	kirkwood-db-88f6282.dtb \
 	kirkwood-dns320.dtb \

arch/arm/boot/dts/kirkwood-b3.dts new file +5 -0

new file mode 100644
index 000000000000..7c675db24b6b
@@ -0,0 +1,199 @@
+/*
+ * Device Tree file for Excito Bubba B3
+ *
+ * Copyright (C) 2013, Andrew Lunn <[email protected]>
+ *

arch/arm/boot/dts/kirkwood-b3.dts new file +21 -0

+ */
+
+/dts-v1/;
+
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
+
+/ {
+	model = "Excito B3";
+	compatible = "excito,b3", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+	memory { /* 512 MB */
+		device_type = "memory";
+		reg = <0x00000000 0x20000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+	};
+
+	mbus {
+		pcie-controller {

arch/arm/boot/dts/kirkwood-b3.dts new file +20 -0

+		pinctrl: pinctrl at 10000 {
+			pmx_button_power: pmx-button-power {
+				marvell,pins = "mpp39";
+				marvell,function = "gpio";
+			};
+			pmx_led_green: pmx-led-green {
+				marvell,pins = "mpp38";
+				marvell,function = "gpio";
+			};
+			pmx_led_red: pmx-led-red {
+				marvell,pins = "mpp41";
+				marvell,function = "gpio";
+			};
+			pmx_led_blue: pmx-led-blue {
+				marvell,pins = "mpp42";
+				marvell,function = "gpio";
+			};
+			pmx_beeper: pmx-beeper {
+				marvell,pins = "mpp40";
+				marvell,function = "gpio";

arch/arm/boot/dts/kirkwood-b3.dts new file +46 -0

+			pinctrl-0 = <&pmx_uart0>;
+			pinctrl-names = "default";
+			status = "okay";
+		};
+
+		spi at 10600 {
+			status = "okay";
+			pinctrl-0 = <&pmx_spi>;
+			pinctrl-names = "default";
+
+			m25p16 at 0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				compatible = "m25p16";
+				reg = <0>;
+				spi-max-frequency = <40000000>;
+				mode = <0>;
+
+				partition at 0 {
+					reg = <0x0 0xc0000>;
+					label = "u-boot";
+				};
+
+				partition at c0000 {
+					reg = <0xc0000 0x20000>;
+					label = "u-boot env";
+				};
+
+				partition at e0000 {
+					reg = <0xe0000 0x120000>;
+					label = "data";
+				};
+			};
+		};
+
+		sata at 80000 {
+			/* One internal, the second as eSATA */
+			status = "okay";
+			nr-ports = <2>;
+		};
+	};
+
+	gpio-leds {
+		/*
+		 * There is one LED "port" on the front and the colours
+		 * mix together giving some interesting combinations.

arch/arm/boot/dts/kirkwood-b3.dts new file +63 -0

+		};
+
+		error_led {
+			label = "bubba3:red:error";
+			gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+		};
+
+		active_led {
+			label = "bubba3:blue:active";
+			gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-0 = <&pmx_button_power>;
+		pinctrl-names = "default";
+
+		power-button {
+			/* On the back */
+			label = "Power Button";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	beeper: beeper {
+		/* 4KHz Piezoelectric buzzer */
+		compatible = "gpio-beeper";
+		pinctrl-0 = <&pmx_beeper>;
+		pinctrl-names = "default";
+		gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+
+	ethphy1: ethernet-phy at 24 {
+		device_type = "ethernet-phy";
+		reg = <24>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
+

Signature · 1 line

1.7.10.4

Hi Andrew,

Quoted 1 line · Andrew Lunn

The Excito Bubba B3 is a home server, single driver NAS box, Wifi

nit, s/driver/drive/

Quoted 6 lines

+ * Note: This requires a new'ish version of u-boot, which disables the
+ * L2 cache. If your B3 silently fails to boot, u-boot is probably too
+ * old. Either upgrade, or consider the following email:
+ *
+ * http://lists.debian.org/debian-arm/2012/08/msg00128.html

Nice, thanks for adding this.

arch/arm/boot/dts/kirkwood-b3.dts line 46

Quoted 1 line

arch/arm/boot/dts/kirkwood-b3.dts new file +1 -0

+	ocp at f1000000 {

I plan on going though and sorting the nodes under the ocp bus for all the dts files during the next cycle. Would you mind sorting these so we have one less to worry about?

arch/arm/boot/dts/kirkwood-b3.dts line 76

Quoted 7 lines

arch/arm/boot/dts/kirkwood-b3.dts new file +7 -0

+		i2c at 11000 {
+			status = "okay";
+			/*
+			 * There is something on the bus at address 0x64.
+			 * Not yet identified what it is, maybe the eeprom
+			 * for the Atheros WiFi chip?
+			 */

Not related to accepting this patch, have you found anything in the stock kernel?

arch/arm/boot/dts/kirkwood-b3.dts line 80

Quoted 5 lines

arch/arm/boot/dts/kirkwood-b3.dts new file +4 -0

+		};
+
+		serial at 12000 {
+			/* Internal on test pins, 3.3v TTL */

Do you have a pointer to a pin layout?

arch/arm/boot/dts/kirkwood-b3.dts line 136

Quoted 4 lines

arch/arm/boot/dts/kirkwood-b3.dts new file +4 -0

+		programming_led {
+			label = "bubba3:green:programming";
+			gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "default-off";

Perhaps we can use 'default-state = "off";' here to avoid the linux-specific property?

Quoted 1 line · Jason Cooper

On Sat, Dec 28, 2013 at 05:12:11PM +0100, Andrew Lunn wrote:

Quoted 5 lines

arch/arm/boot/dts/kirkwood-b3.dts line 46

Quoted 1 line

arch/arm/boot/dts/kirkwood-b3.dts new file +1 -0

+	ocp at f1000000 {

I plan on going though and sorting the nodes under the ocp bus for all the dts files during the next cycle. Would you mind sorting these so we have one less to worry about?

Sure. Sort on what? Address, alphabetic on node name?

Quoted 6 lines

arch/arm/boot/dts/kirkwood-b3.dts line 80

Quoted 4 lines

arch/arm/boot/dts/kirkwood-b3.dts new file +4 -0

+		};
+
+		serial at 12000 {
+			/* Internal on test pins, 3.3v TTL */

Do you have a pointer to a pin layout?

Yes, i can add a URL to an Excito forum page. They are friendly about this, document it themselves.

Quoted 7 lines

arch/arm/boot/dts/kirkwood-b3.dts line 136

Quoted 4 lines

arch/arm/boot/dts/kirkwood-b3.dts new file +4 -0

+		programming_led {
+			label = "bubba3:green:programming";
+			gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "default-off";

Perhaps we can use 'default-state = "off";' here to avoid the linux-specific property?

Sure.

v2 in the next day or two.

Quoted 5 lines

+ * Note: This requires a new'ish version of u-boot, which disables the
+ * L2 cache. If your B3 silently fails to boot, u-boot is probably too
+ * old. Either upgrade, or consider the following email:
+ *
+ * http://lists.debian.org/debian-arm/2012/08/msg00128.html

Nice, thanks for adding this.

From a kernel side, a possible way to address this might be to move

Quoted 7 lines · Jason Cooper

Quoted 5 lines

+ * Note: This requires a new'ish version of u-boot, which disables the
+ * L2 cache. If your B3 silently fails to boot, u-boot is probably too
+ * old. Either upgrade, or consider the following email:
+ *
+ * http://lists.debian.org/debian-arm/2012/08/msg00128.html

Nice, thanks for adding this.

Nifty.. But what is the root cause for the above?

I'm guessing that at some point the the L1 icache has been enabled, the L1 dcache disabled, and the L2 cache enabled?

If the pv_fixup runs with both L1 caches off and an empty L2 then it shouldn't cause a problem.

Quoted 15 lines · Jason Gunthorpe

Quoted 7 lines · Jason Cooper

Quoted 5 lines

+ * Note: This requires a new'ish version of u-boot, which disables the
+ * L2 cache. If your B3 silently fails to boot, u-boot is probably too
+ * old. Either upgrade, or consider the following email:
+ *
+ * http://lists.debian.org/debian-arm/2012/08/msg00128.html

Nice, thanks for adding this.

Nifty.. But what is the root cause for the above?

I'm guessing that at some point the the L1 icache has been enabled, the L1 dcache disabled, and the L2 cache enabled?

Quoted 2 lines

If the pv_fixup runs with both L1 caches off and an empty L2 then it shouldn't cause a problem.

I'm not 100% sure but I think the issue is that the kernel expects to be running with all of the caches off, but u-boot incorrectly left the l2 on. The L2 is probably not empty (because u-boot was using it).

.. and since the problem only shows obviously with multiplatform kernels that have been relocated it could be a broader, subtler issue than just your one board ...

Jason C: What do you think about applying this [untested]?

Or do you think the kernel should support booting with L2 on (this is just two instructions, but they need to be conditional on the CPU type :( :( )?

Quoted 16 lines · Ian Campbell

Quoted 15 lines · Jason Gunthorpe

Quoted 7 lines · Jason Cooper

Quoted 5 lines

+ * Note: This requires a new'ish version of u-boot, which disables the
+ * L2 cache. If your B3 silently fails to boot, u-boot is probably too
+ * old. Either upgrade, or consider the following email:
+ *
+ * http://lists.debian.org/debian-arm/2012/08/msg00128.html

Nice, thanks for adding this.

Nifty.. But what is the root cause for the above?

I'm guessing that at some point the the L1 icache has been enabled, the L1 dcache disabled, and the L2 cache enabled?

Quoted 6 lines

Quoted 2 lines

If the pv_fixup runs with both L1 caches off and an empty L2 then it shouldn't cause a problem.

I'm not 100% sure but I think the issue is that the kernel expects to be running with all of the caches off, but u-boot incorrectly left the l2 on. The L2 is probably not empty (because u-boot was using it).

I think I see the problem now.. The decompressor turns on the L1 dcache, which populates the enabled L2 with write through data. When the decompressor turns the dcache off again the L2 retains some of the kernel image and any data writes done in head.S while the dcache is off could be corrupted if they overlap the L2's retention, specifically the pv_fixup stuff, but other elements could potentially be mangled too.

So all Marvell platforms with their L2 cache controller must boot into the decompressor with the L2 cache completely off, or the kernel needs additional Marvell L2 specific flushing code prior to enabling the MMU :(

.. and since the problem only shows obviously with multiplatform kernels that have been relocated it could be a broader, subtler issue than just your one board ...

Jason C: What do you think about applying this [untested]?

Or do you think the kernel should support booting with L2 on (this is just two instructions, but they need to be conditional on the CPU type :( :( )?

-----
arm: Kirkwood: Log a FW_BUG if the L2 cache is turned on at boot

Linux can't cope if the the L2 cache is enabled at boot. It works sometimes, if the data writes head.S does during the L1 cache-off period do not overlap with lines in the L2.

This is unlikely if CONFIG_ARM_PATCH_PHYS_VIRT is used, as the decompressor will pull a chunk of the kernel code into L2 cache.

Signed-off-by Jason Gunthorpe <[email protected]>

arch/arm/mm/cache-feroceon-l2.c +2 -1

index 48bc3c0..68781a4 100644
@@ -331,7 +331,8 @@ static void __init enable_l2(void)
                        enable_icache();
                if (d)
                        enable_dcache();
-       }
+       } else
+               pr_err(FW_BUG "Feroceon L2: bootloader left the L2 cache on!\n");
 }
 
 void __init feroceon_l2_init(int __l2_wt_override)

Jason

Quoted 1 line

Jason C: What do you think about applying this [untested]?

I'm of the opinion that the kernel shouldn't assume the state of the system when it begins execution. Sure it's nice to point fingers at the bootloader (especially since it's obviously wrong in this situation), but we need Linux to boot on systems with non-upgradeable bootloaders which may be broken. I'm specifically thinking about hobbyists modifying boxes they bought at $bigbox stores.

So, I'd prefer to handle this more gracefully. I don't have much experience at the low-level init of the caches, couldn't we enable and flush rather than throwing the error?

Quoted 8 lines · Jason Cooper

Quoted 1 line

Jason C: What do you think about applying this [untested]?

I'm of the opinion that the kernel shouldn't assume the state of the system when it begins execution. Sure it's nice to point fingers at the bootloader (especially since it's obviously wrong in this situation), but we need Linux to boot on systems with non-upgradeable bootloaders which may be broken. I'm specifically thinking about hobbyists modifying boxes they bought at $bigbox stores.

I liked the idea of your impedance matcher fixing up bootloader problems. It would be pretty easy to have a feroceon specific path in the impedance matcher to disable the L2.

Quoted 3 lines

So, I'd prefer to handle this more gracefully. I don't have much experience at the low-level init of the caches, couldn't we enable and flush rather than throwing the error?

It cannot be solved in cache-feroceon-l2.c.

In many cases you won't even get that far:
- It will blow up in head.S when the cache is off: decompressor wrote writeback data to into the L2 and uncached fetches see memory content prior to decompression
- It will blow up after head.S enables the L1: decompressor wrote data into the L2 but the relocation writes done with the L1 off made changes to memory that were not captured in the L2.

So to solve it gracefully it has to be done before the decompressor enables the L1. Which leaves the bootloader, impedance matcher or decompressor startup code as possible places.

The code required is a flush invalidate and then disable of the L2 cache, which is only about 5 instructions, but they must be conditionalized somehow on the CPU type :(

The purpose of my patch is to highlight the problem to the bootloader people. If you luck out and successfully boot with the L2 cache enabled you can at least see the message that the bootloader is wrong.

Quoted 3 lines

So, I'd prefer to handle this more gracefully. I don't have much experience at the low-level init of the caches, couldn't we enable and flush rather than throwing the error?

It cannot be solved in cache-feroceon-l2.c.

In many cases you won't even get that far:
- It will blow up in head.S when the cache is off: decompressor wrote writeback data to into the L2 and uncached fetches see memory content prior to decompression
- It will blow up after head.S enables the L1: decompressor wrote data into the L2 but the relocation writes done with the L1 off made changes to memory that were not captured in the L2.

Quoted 6 lines

Quoted 3 lines

So, I'd prefer to handle this more gracefully. I don't have much experience at the low-level init of the caches, couldn't we enable and flush rather than throwing the error?

It cannot be solved in cache-feroceon-l2.c.

Quoted 7 lines

In many cases you won't even get that far:
- It will blow up in head.S when the cache is off: decompressor wrote writeback data to into the L2 and uncached fetches see memory content prior to decompression
- It will blow up after head.S enables the L1: decompressor wrote data into the L2 but the relocation writes done with the L1 off made changes to memory that were not captured in the L2.

My impression with booting a lot of times while doing i bisect, was that it got as far as:

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.13.0-rc1-dirty (lunn at laptop) (gcc version 4.4.5 (Debian 4.4.5-8) ) #7 PREEMPT Fri Jan 3 09:25:07 CST 2014
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family
Memory policy: ECC disabled, Data cache writeback

every time.

It does however seem possible to insert platform specific code soon after it prints:

Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family

I'm of the opinion that the kernel shouldn't assume the state of the system when it begins execution.

Quoted 2 lines · Jason Cooper

I'm of the opinion that the kernel shouldn't assume the state of the system when it begins execution.

Rubbish. The kernel's requirements are well documented, and have been for years. The reason we've documented it is because it _matters_, and it's hard to sort out this crap before the kernel starts.

Think about it - think about how many different L2 caches there are out there.

Think about how difficult it is to locate the L2 cache controller when you don't know what platform you're running on.

Think about how difficult it is to disable the L2 cache.

Think about how difficult it is to flush the L2 cache, when you don't know what sort it is, where it's located, or what instructions to use to do that.

The kernel cares about its boot environment beacuse of these issues.