ARM: BCM5301X: initial support for the BCM5301X/BCM470X SoCs with ARM CPU

This patch adds support for the BCM5301X/BCM470X SoCs with an ARM CPUs. Currently just booting to a shell is working and nothing else, no Ethernet, wifi, flash, ...

This SoC is used in small office and home router with Broadcom SoCs. This code should support the BCM4707, BCM4708, BCM4709, BCM53010, BCM53011 and BCM53012 SoC. It uses one or two ARM Cortex A9 Cores, some highlights are 2 PCIe 2.0 controllers, 4 Gigabit Ethernet MACs and a USB 3.0 host controller.

This SoC uses a dual core CPU, but this is currently not implemented. More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

Signed-off-by Hauke Mehrtens <[email protected]>

---
 Documentation/devicetree/bindings/arm/bcm4708.txt |    8 +++
 MAINTAINERS                                       |    8 +++
 arch/arm/Makefile                                 |    2 +-
 arch/arm/configs/multi_v7_defconfig               |    1 +
 arch/arm/mach-bcm/Kconfig                         |   21 ++++++++
 arch/arm/mach-bcm/Makefile                        |    1 +
 arch/arm/mach-bcm/bcm5301x.c                      |   59 +++++++++++++++++++++
 7 files changed, 99 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm4708.txt
 create mode 100644 arch/arm/mach-bcm/bcm5301x.c

Documentation/devicetree/bindings/arm/bcm4708.txt new file +8 -0

new file mode 100644
index 0000000..6b0f49f
@@ -0,0 +1,8 @@
+Broadcom BCM4708 device tree bindings
+-------------------------------------------
+
+Boards with the BCM4708 SoC shall have the following properties:
+
+Required root node property:
+
+compatible = "brcm,bcm4708";

MAINTAINERS +8 -0

index bf61e04..b38f141 100644
@@ -1795,6 +1795,14 @@ F:	arch/arm/boot/dts/bcm2835*
 F:	arch/arm/configs/bcm2835_defconfig
 F:	drivers/*/*bcm2835*
 
+BROADCOM BCM5301X ARM ARCHICTURE
+M:	Hauke Mehrtens <[email protected]>
+L:	linux-arm-kernel at lists.infradead.org
+S:	Maintained
+F:	arch/arm/mach-bcm/bcm5301x.c
+F:	arch/arm/boot/dts/bcm5301*
+F:	arch/arm/boot/dts/bcm470*
+
 BROADCOM TG3 GIGABIT ETHERNET DRIVER
 M:	Nithin Nayak Sujir <[email protected]>
 M:	Michael Chan <[email protected]>

arch/arm/Makefile +1 -1

index c0ac0f5..230b5d7 100644
@@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 # Machine directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
 machine-$(CONFIG_ARCH_AT91)		+= at91
-machine-$(CONFIG_ARCH_BCM)		+= bcm
+machine-y				+= bcm
 machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx

arch/arm/configs/multi_v7_defconfig +1 -0

index fe0bdc3..f449bd7 100644
@@ -6,6 +6,7 @@ CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_ARCH_BCM=y
+CONFIG_ARCH_BCM5301X=y
 CONFIG_GPIO_PCA953X=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_KEYSTONE=y

arch/arm/mach-bcm/Kconfig +0 -0

index f112895..979433b 100644

arch/arm/mach-bcm/Kconfig +17 -0

+	select ARM_GIC
+	select HAVE_CLK
+	select GENERIC_CLOCKEVENTS
+	select GENERIC_TIME
+	select ARM_GLOBAL_TIMER
+	help
+	  Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.
+
+	  This is a network SoC line mostly used in home routers and
+	  wifi access points.
+	  This inclused the following SoC: BCM53010, BCM53011, BCM53012,
+	  BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707,
+	  BCM4708 and BCM4709.
+
+	  Do not confuse this with the BCM4760 which is a totally
+	  different SoC or with the older BCM47XX and BCM53XX based
+	  network SoC using a MIPS CPU, they are supported by arch/mips/bcm47xx

arch/arm/mach-bcm/Makefile +1 -0

index 6adb6aec..b5b8046 100644
@@ -13,3 +13,4 @@
 obj-$(CONFIG_ARCH_BCM)		:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_bcm_kona_smc_asm.o	:=-Wa,-march=armv7-a$(plus_sec)
+obj-$(CONFIG_ARCH_BCM5301X)	+= bcm5301x.o

arch/arm/mach-bcm/bcm5301x.c new file +0 -0

new file mode 100644
index 0000000..5168f94

arch/arm/mach-bcm/bcm5301x.c new file +21 -0

+#include <linux/clocksource.h>
+#include <linux/clk-provider.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/signal.h>
+
+static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason, possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void __init bcm5301x_init_early(void)

arch/arm/mach-bcm/bcm5301x.c new file +3 -0

+	.init_time = bcm5301x_timer_init,
+	.dt_compat = bcm5301x_dt_compat,
+MACHINE_END

Signature · 1 line

1.7.10.4

This patch adds support for the BCM5301X/BCM470X SoCs with an ARM CPUs. Currently just booting to a shell is working and nothing else, no Ethernet, wifi, flash, ...

This SoC is used in small office and home router with Broadcom SoCs. This code should support the BCM4707, BCM4708, BCM4709, BCM53010, BCM53011 and BCM53012 SoC. It uses one or two ARM Cortex A9 Cores, some highlights are 2 PCIe 2.0 controllers, 4 Gigabit Ethernet MACs and a USB 3.0 host controller.

This SoC uses a dual core CPU, but this is currently not implemented. More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

arch/arm/mach-bcm/bcm5301x.c new file +9 -0

+static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason, possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+

Quoted 13 lines · Hauke Mehrtens

This patch adds support for the BCM5301X/BCM470X SoCs with an ARM CPUs. Currently just booting to a shell is working and nothing else, no Ethernet, wifi, flash, ...

This SoC is used in small office and home router with Broadcom SoCs. This code should support the BCM4707, BCM4708, BCM4709, BCM53010, BCM53011 and BCM53012 SoC. It uses one or two ARM Cortex A9 Cores, some highlights are 2 PCIe 2.0 controllers, 4 Gigabit Ethernet MACs and a USB 3.0 host controller.

This SoC uses a dual core CPU, but this is currently not implemented. More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

[...]

Quoted 9 lines

arch/arm/mach-bcm/bcm5301x.c new file +9 -0

+static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason, possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+

arch/arm/mach-bcm/bcm5301x.c line 36

Quoted 10 lines

arch/arm/mach-bcm/bcm5301x.c new file +10 -0

+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void __init bcm5301x_init_early(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}

Surely you can't be serious?

At least, we need a pretty good explanation of what *exactly* is causing these spurious aborts before we start ignoring them unconditionally like this. You're effectively masking an extremely serious error indicator with this change.

Quoted 22 lines · Will Deacon

Quoted 9 lines

arch/arm/mach-bcm/bcm5301x.c new file +9 -0

+static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason, possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+

arch/arm/mach-bcm/bcm5301x.c line 36

Quoted 10 lines

arch/arm/mach-bcm/bcm5301x.c new file +10 -0

+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void __init bcm5301x_init_early(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}

Surely you can't be serious?

Quoted 4 lines

At least, we need a pretty good explanation of what *exactly* is causing these spurious aborts before we start ignoring them unconditionally like this. You're effectively masking an extremely serious error indicator with this change.

This fault occurs once every boot sometime early in the boot process, but the actual time this happens varies randomly.

Sadly I do not understand this completely, and I copied this from the vendor BSP with the corresponding code documentation. They think CFE (Common Firmware Environment, the bootloader used on these devices), did something wrong, but I do not have the actual source of CFE and I do not have the chip documentation. This occurs just once as far as I have seen this, we could just catch the first one. Changing the boot loader is also not an option, because I want to use this code on devices already shipped to costumers and I do not have access to the boot loader source code.

Do you know what this fault normally indicates?

Quoted 7 lines

Quoted 4 lines

At least, we need a pretty good explanation of what exactly is causing these spurious aborts before we start ignoring them unconditionally like this. You're effectively masking an extremely serious error indicator with this change.

This fault occurs once every boot sometime early in the boot process, but the actual time this happens varies randomly.

Well that's interesting in itself. It sounds like we don't know *for sure* whether the abort is triggered by Linux. Since the abort is imprecise, the timing will vary.

Quoted 11 lines · Will Deacon

Quoted 7 lines

Quoted 4 lines

At least, we need a pretty good explanation of what exactly is causing these spurious aborts before we start ignoring them unconditionally like this. You're effectively masking an extremely serious error indicator with this change.

This fault occurs once every boot sometime early in the boot process, but the actual time this happens varies randomly.

Well that's interesting in itself. It sounds like we don't know *for sure* whether the abort is triggered by Linux. Since the abort is imprecise, the timing will vary.

It might be possible to find out the culprit if you just enter an endless loop in the early kernel boot code. If you enter the loop before Linux does something wrong, it won't crash, otherwise it will. After that, you could bisect the boot process by moving the busy loop around.

If it even crashes at the point where Linux gets entered, it's a bug in the boot loader.

Quoted 18 lines · Arnd Bergmann

Quoted 11 lines · Will Deacon

Quoted 7 lines

Quoted 4 lines

At least, we need a pretty good explanation of what exactly is causing these spurious aborts before we start ignoring them unconditionally like this. You're effectively masking an extremely serious error indicator with this change.

This fault occurs once every boot sometime early in the boot process, but the actual time this happens varies randomly.

Well that's interesting in itself. It sounds like we don't know *for sure* whether the abort is triggered by Linux. Since the abort is imprecise, the timing will vary.

It might be possible to find out the culprit if you just enter an endless loop in the early kernel boot code. If you enter the loop before Linux does something wrong, it won't crash, otherwise it will. After that, you could bisect the boot process by moving the busy loop around.

Quoted 2 lines

If it even crashes at the point where Linux gets entered, it's a bug in the boot loader.

Can you give Arnd's suggestion a go please Hauke?

Quoted 19 lines · Will Deacon

Quoted 18 lines · Arnd Bergmann

Quoted 11 lines · Will Deacon

Quoted 7 lines

Quoted 4 lines

At least, we need a pretty good explanation of what exactly is causing these spurious aborts before we start ignoring them unconditionally like this. You're effectively masking an extremely serious error indicator with this change.

This fault occurs once every boot sometime early in the boot process, but the actual time this happens varies randomly.

Well that's interesting in itself. It sounds like we don't know *for sure* whether the abort is triggered by Linux. Since the abort is imprecise, the timing will vary.

It might be possible to find out the culprit if you just enter an endless loop in the early kernel boot code. If you enter the loop before Linux does something wrong, it won't crash, otherwise it will. After that, you could bisect the boot process by moving the busy loop around.

Quoted 4 lines

Quoted 2 lines

If it even crashes at the point where Linux gets entered, it's a bug in the boot loader.

Can you give Arnd's suggestion a go please Hauke?

Hi

I just tried that, but it did not crash in the loop. :-(

Now, with 3.11-rc3 it crashed reproducible after Freeing unused kernel memory, see this:

[    0.859198] Freeing unused kernel memory: 1124K (c0260000 - c0379000)
[    0.866298] Unhandled fault: imprecise external abort (0x1c06) at
0xb6f8b005
[    0.873538] Kernel panic - not syncing: Attempted to kill init!

exitcode=0x00000007

Do you have some more informations about this type of error?

Quoted 20 lines · Hauke Mehrtens

Quoted 19 lines · Will Deacon

Quoted 18 lines · Arnd Bergmann

Quoted 11 lines · Will Deacon

Quoted 7 lines

Quoted 4 lines

At least, we need a pretty good explanation of what exactly is causing these spurious aborts before we start ignoring them unconditionally like this. You're effectively masking an extremely serious error indicator with this change.

This fault occurs once every boot sometime early in the boot process, but the actual time this happens varies randomly.

Well that's interesting in itself. It sounds like we don't know *for sure* whether the abort is triggered by Linux. Since the abort is imprecise, the timing will vary.

It might be possible to find out the culprit if you just enter an endless loop in the early kernel boot code. If you enter the loop before Linux does something wrong, it won't crash, otherwise it will. After that, you could bisect the boot process by moving the busy loop around.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

If it even crashes at the point where Linux gets entered, it's a bug in the boot loader.

Can you give Arnd's suggestion a go please Hauke?

Hi

I just tried that, but it did not crash in the loop. :-(

Turn that frown around -- this is a useful result! It means that the abort is likely caused by the kernel, rather than the boot loader (although we still can't rule it out, it depends where you put the loop).

Quoted 9 lines

Now, with 3.11-rc3 it crashed reproducible after Freeing unused kernel memory, see this:

[    0.859198] Freeing unused kernel memory: 1124K (c0260000 - c0379000)
[    0.866298] Unhandled fault: imprecise external abort (0x1c06) at
0xb6f8b005
[    0.873538] Kernel panic - not syncing: Attempted to kill init!

exitcode=0x00000007

Quoted 1 line

Do you have some more informations about this type of error?

Hmm, so that's now exploding on a user address. Is this an A9-based SoC? If so, can you try disabling PL310 (CONFIG_CACHE_L2X0) and see if it makes a different please?

Quoted 3 lines · Will Deacon

Hmm, so that's now exploding on a user address. Is this an A9-based SoC? If so, can you try disabling PL310 (CONFIG_CACHE_L2X0) and see if it makes a different please?

This is a A9-based SoC.

I already had PL310 disabled, now I tried to activate it, but I do not see any difference.

[    1.049381] Freeing unused kernel memory: 1128K (c0261000 - c037b000)
[    1.056501] Unhandled fault: imprecise external abort (0x1c06) at
0xb6f34005
[    1.063738] Kernel panic - not syncing: Attempted to kill init!

exitcode=0x00000007

Now, with 3.11-rc3 it crashed reproducible after Freeing unused kernel memory, see this:

[    0.859198] Freeing unused kernel memory: 1124K (c0260000 - c0379000)
[    0.866298] Unhandled fault: imprecise external abort (0x1c06) at
0xb6f8b005
[    0.873538] Kernel panic - not syncing: Attempted to kill init!

exitcode=0x00000007

Do you have some more informations about this type of error?

This uses the newly added BCM5301X SoC code.

Signed-off-by Hauke Mehrtens <[email protected]>

---
 arch/arm/boot/dts/Makefile                  |    1 +
 arch/arm/boot/dts/bcm4708-netgear-r6250.dts |   20 ++++++++
 arch/arm/boot/dts/bcm4708.dtsi              |   74 +++++++++++++++++++++++++++
 3 files changed, 95 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm4708-netgear-r6250.dts
 create mode 100644 arch/arm/boot/dts/bcm4708.dtsi

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

index 641b3c9..6329f2d 100644
@@ -43,6 +43,7 @@ dtb-$(CONFIG_ARCH_AT91)	+= sama5d35ek.dtb
 
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
 dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb
+dtb-$(CONFIG_ARCH_BCM5301X) += bcm4708-netgear-r6250.dtb
 dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
 	da850-evm.dtb
 dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \

arch/arm/boot/dts/bcm4708-netgear-r6250.dts new file +20 -0

new file mode 100644
index 0000000..34875f6
@@ -0,0 +1,20 @@
+/*
+ * Broadcom BCM470X / BCM5301X arm platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/dts-v1/;
+
+#include "bcm4708.dtsi"
+
+/ {
+	compatible = "netgear,r6250v1", "brcm,bcm4708";
+	model = "Netgear R6250 V1 (BCM4708)";
+
+	memory {
+		reg = <0x00000000 0x08000000>;
+	};
+};

arch/arm/boot/dts/bcm4708.dtsi new file +10 -0

new file mode 100644
index 0000000..fbf1dcf
@@ -0,0 +1,74 @@
+/*
+ * Broadcom BCM470X / BCM5301X ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>

arch/arm/boot/dts/bcm4708.dtsi new file +54 -0

+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+		};
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk_periph: periph {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <400000000>;
+		};
+	};
+
+	uart at 18000300 {
+		compatible = "ns16550";
+		reg = <0x18000300 0x100>;
+		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+		clock-frequency = <100000000>;
+	};
+
+	uart at 18000400 {
+		compatible = "ns16550";
+		reg = <0x18000400 0x100>;
+		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+		clock-frequency = <100000000>;
+	};
+
+	gic: interrupt-controller at 19021000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x19021000 0x1000>,
+		      <0x19020100 0x100>;
+	};
+
+	timer at 19020200 {
+		compatible = "arm,cortex-a9-global-timer";
+		reg = <0x19020200 0x100>;
+		interrupts = <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&clk_periph>;
+	};
+};

Signature · 1 line

1.7.10.4