ARM: add support for BCM2708/BCM2835 and Raspberry Pi

The BCM2708 is an ARM SoC from Broadcom. It is the primary SoC in a series which contains the BCM2835 amongst other variants. This patch adds very basic support for this series of SoCs, under the BCM2708 name.

http://www.broadcom.com/products/BCM2835
http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pd

Note that the documentation in the latter .pdf assumes the MMU setup that's used on the "VideoCore" companion processor, and does not document physical peripheral addresses. Subtract 0x5e000000 to obtain the physical addresses.

The BCM2835 SoC is used in the Raspberry Pi. This patch also adds a minimal device tree for this board; enough to see some very early kernel boot messages through earlyprintk.

http://www.raspberrypi.org/.

This series was extracted from git://github.com/lp0/linux.git branch rpi-next or rpi-linear from 3-4 months ago, and significantly stripped down and modified since. The work in that branch was signed-off-by:

Chris Boot <[email protected]>
Simon Arlott <sa.me.uk> [sic]

---
To do:
* Interrupt controller and timer aren't implemented, so the kernel only boots as far as "Calibrating delay loop...". However, this patch is intended solely to provide the very basic infra-structure so people can start filling in the gaps in mainline rather than downstream.
* No device drivers are implemented yet.

Questions:
* It is asserted (I believe by Broadcom) that the BCM2835 is the only SoC in the series likely to see Linux support. Irrespective, those working on BCM2835 support downstream (see git URL above) have chosen to name the kernel support after the primary SoC (BCM2708) rather than the particular instance in use on the Raspberry Pi (BCM2835). I've followed that here, although I wonder if it's really the correct thing to do?
* Should bcm2708_map_io() map the entire peripheral address range, or only the debug UART iff DEBUG_LL is enabled? Presumably anything other than the UART should be using of_iomap(), so doesn't need to be statically mapped; are the IRQ controller/timer set up before of_iomap() will work with non-static mappings?
* Does the (currently somewhat arbitrary) value for BCM2708_PERIPH_VIRT matter; should it be picked to align nicely with any particular part of the kernel's virtual address layout?

---
 arch/arm/Kconfig                                 |   19 ++++
 arch/arm/Makefile                                |    1 +
 arch/arm/boot/dts/bcm2835-rpi-b.dts              |   12 +++
 arch/arm/boot/dts/bcm2835.dtsi                   |   10 +++
 arch/arm/configs/bcm2708_defconfig               |  102 ++++++++++++++++++++++
 arch/arm/mach-bcm2708/Makefile                   |    1 +
 arch/arm/mach-bcm2708/Makefile.boot              |    5 ++
 arch/arm/mach-bcm2708/common.c                   |   80 +++++++++++++++++
 arch/arm/mach-bcm2708/include/mach/bcm2708_soc.h |   29 ++++++
 arch/arm/mach-bcm2708/include/mach/debug-macro.S |   24 +++++
 arch/arm/mach-bcm2708/include/mach/hardware.h    |   18 ++++
 arch/arm/mach-bcm2708/include/mach/timex.h       |   26 ++++++
 arch/arm/mach-bcm2708/include/mach/uncompress.h  |   49 +++++++++++
 13 files changed, 376 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm2835-rpi-b.dts
 create mode 100644 arch/arm/boot/dts/bcm2835.dtsi
 create mode 100644 arch/arm/configs/bcm2708_defconfig
 create mode 100644 arch/arm/mach-bcm2708/Makefile
 create mode 100644 arch/arm/mach-bcm2708/Makefile.boot
 create mode 100644 arch/arm/mach-bcm2708/common.c
 create mode 100644 arch/arm/mach-bcm2708/include/mach/bcm2708_soc.h
 create mode 100644 arch/arm/mach-bcm2708/include/mach/debug-macro.S
 create mode 100644 arch/arm/mach-bcm2708/include/mach/hardware.h
 create mode 100644 arch/arm/mach-bcm2708/include/mach/timex.h
 create mode 100644 arch/arm/mach-bcm2708/include/mach/uncompress.h

index 88ff698..3c11dce 100644
@@ -349,6 +349,25 @@ config ARCH_AT91
 	  This enables support for systems based on Atmel
 	  AT91RM9200 and AT91SAM9* processors.
 
+config ARCH_BCM2708
+	bool "Broadcom BCM2708 family"
+	select ARCH_WANT_OPTIONAL_GPIOLIB
+	select ARM_AMBA
+	select ARM_ERRATA_411920
+	select ARM_TIMER_SP804
+	select CLKDEV_LOOKUP
+	select COMMON_CLK
+	select CPU_V6
+	select GENERIC_CLOCKEVENTS
+	select MULTI_IRQ_HANDLER
+	select SPARSE_IRQ
+	select USE_OF
+	select WATCHDOG
+	help
+	  This enables support for the Broadcom BCM2708 SoC series. The
+	  BCM2835 is one such SoC in this series. The Raspberry Pi uses
+	  the BCM2835.
+
 config ARCH_BCMRING
 	bool "Broadcom BCMRING"
 	depends on MMU

index 30eae87..853c761 100644
@@ -136,6 +136,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_BCM2708)		:= bcm2708
 machine-$(CONFIG_ARCH_BCMRING)		:= bcmring
 machine-$(CONFIG_ARCH_CLPS711X)		:= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		:= cns3xxx

new file mode 100644
index 0000000..7e43197
@@ -0,0 +1,12 @@
+/dts-v1/;
+/memreserve/ 0x0c000000 0x04000000;
+/include/ "bcm2835.dtsi"
+
+/ {
+	model = "Raspberry Pi Model B";
+	compatible = "raspberrypi,model-b", "broadcom,bcm2835", "broadcom,bcm2708";
+
+	memory {
+		reg = <0 0x10000000>;
+	};
+};

new file mode 100644
index 0000000..221a49a
@@ -0,0 +1,10 @@
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "broadcom,bcm2835", "broadcom,bcm2708";
+	model = "BCM2835";
+
+	chosen {
+		bootargs = "earlyprintk";			/* Set by VideoCore */
+	};
+};

new file mode 100644
index 0000000..f95691b
@@ -0,0 +1 @@
+obj-y += common.o

new file mode 100644
index 0000000..0831fd1
@@ -0,0 +1,5 @@
+   zreladdr-y := 0x00008000
+params_phys-y := 0x00000100
+initrd_phys-y := 0x00800000
+
+dtb-y += bcm2835-rpi-b.dtb

new file mode 100644
index 0000000..4ddeb4e
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2012 Stephen Warren
+ *
+ * Derived from code:
+ * Copyright (C) 2010 Broadcom
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __MACH_BCM2708_BCM2708_SOC_H__
+#define __MACH_BCM2708_BCM2708_SOC_H__
+
+#include <asm/sizes.h>
+
+#define BCM2708_PERIPH_BASE	0x20000000
+#define BCM2708_PERIPH_VIRT	0xf0000000
+#define BCM2708_PERIPH_SIZE	SZ_16M
+#define BCM2708_DEBUG_BASE	0x20201000
+#define BCM2708_DEBUG_VIRT	0xf0201000
+
+#endif

new file mode 100644
index 0000000..ef71e41
@@ -0,0 +1,24 @@
+/*
+ * Debugging macro include header
+ *
+ * Copyright (C) 2012 Stephen Warren
+ *
+ * Derived from code:
+ *  Copyright (C) 2010 Broadcom
+ *  Copyright (C) 1994-1999 Russell King
+ *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <mach/bcm2708_soc.h>
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =BCM2708_DEBUG_BASE
+	ldr	\rv, =BCM2708_DEBUG_VIRT
+	.endm
+
+#include <asm/hardware/debug-pl01x.S>

new file mode 100644
index 0000000..2b15d0b
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2012 Stephen Warren
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __MACH_BCM2708_HARDWARE_H__
+#define __MACH_BCM2708_HARDWARE_H__
+
+#endif

new file mode 100644
index 0000000..ca67219
@@ -0,0 +1,26 @@
+/*
+ *  BCM2708 system clock frequency
+ *
+ *  Copyright (C) 2010 Broadcom
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#ifndef __ASM_ARCH_TIMEX_H
+#define __ASM_ARCH_TIMEX_H
+
+#define CLOCK_TICK_RATE		(1000000)
+
+#endif

1.7.9.5

Very nice!

ok

Doesn't matter too much. Depending on how different the various broadcom SoCs actually are, we might even name this mach-bcm and eventually try to merge the existing bcmring into it.

Mapping the entire range is fine, as long as it's not too large. This will end up using large pages for the mapping, which is a bit more efficient, and any call to of_iomap or ioremap will just return the same address rather than adding another mapping.

The only requirement is that it's inside of the vmalloc area described in Documentation/arm/memory.txt. 0xf0000000 is fine here.

I've some stuff for the BCM4760. Working at clean-room patches, which is easy because the reference published GPL sources [0] are based on 2.6.28 and may look scary (190k lines of register definitions header file, completely broken and unused monster to manage clocks, no pinctrl, old-style gpios, reimplementation of pl011, pl080 - old style dma, to say a few).

Moreover many IP blocks are already in the kernel (PL011, PL081, sdhci, dwc-usb2 in the device-only implementation of s3c-hsotg).

It's incomplete, has a lot of issues. sdhci and usb not working. PMU BCM59040 is barely implemented, only regulators. But it can boot from initramfs, minimal user space works. Yeah... a side project, mostly a continous-study project.

I could find some similarities with something in bcmring, while grepping, but I've never dig into it. I also quickly looked into the Raspberry PI SoC but I could not find anything familiar. However there could be some code to share. I'll manage a first post of these patches if interested.

Regards,
Domenico

[0] http://www.tomtom.com/page.php?Page=gpl

The naming gets increasingly confusing. I thought that bcm47xx were MIPS based router chips, but it seems their number have no meaning at all. Reminds me of IBM's four digit product codes ;-)

If the code looks good, we can always merge it and see how it progresses, maybe other people are also interested in helping out. Of course if it just ends up being stale with nobody working on completing it, we can remove it again just as quickly. We just had a discussion about stale platforms at the ARM mini summit in San Diego. IMHO if a port gets started and then nobody works on filling the gaps for two years, we should remove it again.

Ok. If code for a new platform that is like bcmring were to come out of Broadcom, I'd ask them to clean that up first and merge the two, but if you do a cleanroom implementation, that's probably fine to go in separately. We might actually end up removing bcmring eventually.

Arnd

One of the issues there is that you don't know if the reason it's not receiving patches or comments is because it works and people are using it, and they don't have anything to report against it.

That's certainly true of a number of platforms we currently have.

And then there's the ones I run services on which I don't tend to reboot very often. I'm currently looking at one which is coming up to 1000 days uptime which has had zero problems on a 2.6.32.8 kernel - in fact it's the one which provides www.arm.linux.org.uk and I'm typing this email message on...

22:54:19 up 938 days, 9:27, 11 users, load average: 0.21, 0.08, 0.01

so in that case I'm not going to know if anything is broken on an IOP32x kernel until that gets rebooted (which it will do soon because I want to change its disks - but hopefully not before 62 days time.)

I would also like to know the usefulness/completeness requirements of new platforms.

Expecting the latest designs in each area, what is wanted for a first submission, besides the core stuff required for booting?

- clocks
- gpios
- pinctrl
- devicetree
- uarts
- dma
- i2c
- ...

For instance, I'm absolutely not interested in audio, displays and GPUs at the moment, at least not those equipping this board. So I will not spend any time to contribute anything of them. Would this be a stopper?

Regards,
Domenico

The only real requirements that I have for new platforms are

a) the code has to look reasonable and follow the quality standards, in particular using all the generic subsystems (e.g. irqchip, clocksource, common-clock, mtd, pinctrl, dmaengine, asoc, regulator, pwm) where applicable. You don't have to use all of them, but if you have a driver for one of these, you must use the common code instead of reimplementing it differently.

b) a commitment from the submitter to keep looking after the platform, and review bug fixes and other code changes that are submitted by other people.

There is no need for an initial submission to be complete in any way. In fact I would argue that basically none of the big ARMv7 platforms (omap, exynos, imx, ux500, msm, mmp, ...) are complete because they are all lacking proper graphics drivers.

Having the first version be able to boot to a shell prompt is certainly a good thing, but I would put the entry bar as low as possible really and rather take nice looking work-in-progress code early than review a large amount of code all at once and have to tell the submitters that they got something fundamentally wrong and need to redo everything.

Arnd

No one is interested in removing a platform that is used, but it has been somewhat discouraging when there have been long-standing build breakages even on defconfigs for some of them. Without rattling the cage a bit, it's hard to find out if anyone actually cares about them enough to build and boot an upstream kernel at least every release or so.

And yes, in some cases they definitely do. Just see ks8695 as of the last week -- we've even got someone stepping up to take on maintainership (thanks Greg!).

-Olof

I was specifically saying "a port gets started", not "a port is fully working". The example I was thinking of is the mach-cns3xxx, which was introduced in a very minimal state about 2 years ago. The only users I could find on the internet are on OpenWRT, which adds support for an actual board file (upstream only has the evaluation board) as well as SMP, clock, i2c, ethernet, gpio, and a bunch of bug fixes[1]. I'd say we should either find someone who is willing to submit the patches upstream and make sure they work with at least one version, or we can remove what we have today because it's evidently not used.

Of course, one of the main rules of Linux development is that we don't break stuff, so whenever we remove something that looks like it's not used and someone complains, we should revert the patch to put the code back ASAP.

The platforms that we talked about removing during the ARM mini summit are ks8695, h720x, l7200, netx, pnx4008, w90x900, ixp4xx and bcmring. I've already heard back from people involved in almost all of those, with pretty clear statements:

* ks8695 is in active use, but was missing a maintainer. Greg Ungerer stepped up and already submitted new board files for hardware that he is using.

* ixp4xx is (as expected) actively used, but a lot of patches are stuck in openwrt[2] and not getting submitted.
Greg also submitted a regression fix, Ben Hutchins promised another fix from Debian.

* h720x is pretty much dead, the original authors seem to not be interested any more, we just need to decide how and when to remove it.

* netx is used happily and just needs a contact address.

* pnx4008 is very dead and getting removed in 3.7.

* bcmring is getting orphaned and will likely get removed if nobody steps up as a maintainer to clean it up.

* l7200 was already removed two years ago and a single file has crept back in from a bad merge without anyone noticing.

* no news from w90x900, still need to contact the people who were last working on them. May still be alive considering that we removed it's nuc900 sibling and the maintainers were still active on it back then. A quick online search shows that the chip is actively being marketed and there is a BSP that adds a few device drivers (usbgadget, i2c, asoc, [Cc'd Wan ZongShun, the maintainer, on this email]

Arnd

[1] https://dev.openwrt.org/browser/trunk/target/linux/cns3xxx/patches-3.3
[2] https://dev.openwrt.org/browser/trunk/target/linux/ixp4xx/patches-3.3

On Sun, 09 Sep 2012 03:16:54 +0200, Arnd Bergmann <[email protected]> wrote:

<snip>

For some time now you have to have clocks support to be able to get SMP and co working. Without that and DT it doesn't really make sense to submit those patches.

<snip>

Mostly the same as above. Don't forget that DT support will essentially get rid of all separate board support files, so those patches will have to be translated to dts files instead.

Since I'm doing all the OpenWrt work (as well as upstreaming non-ARM stuff) in my free time, things got stuck and will likely stay that way for another month or so.

Imre

The SoC does actually have two types of serial port; a PL011 which we're using as the primary UART, and a 16C650-alike port. There's no PL010 present. I'll strip this down to just PL011 support since that's all that's in use right now.

This was originally named bcm2708.c downstream, but I renamed it to common.c following the example of mach-picoxcell and mach-zynq, which IIRC you had pointed out as exemplary platforms. Still, I can rename it back if you want.

OK. It's required right now though. I assume we should aim to check this in for 3.7. Should I rebase this patch on top of whatever change removes the need for timex.h? Such a patch doesn't appear to be in linux-next right now though.

It's not a big thing either way. Highbank and socfpga are also good examples and they use the name of the platform.

Let's not worry about it for now, it's easy enough to remove later.

Arnd

(sorry for the dup Stephen, forgot to reply all :-/)

Great work! I'm glad to see this heading upstream :)

I've used Simon's tree before and it will boot up all the way with UART support (no graphics, usb, network). I also think it has a fully populated device
tree. Why, in particular, did you strip it down?

I'm new to the ARM SoC upstreaming scene so there might be a obvious reason of which I'm not aware.

--
Seth

I don't know why you're using the rpi-linear branch when the rpi-split branch has the same content but everything already split into separate patches...

It has supported graphics for a while:
https://github.com/raspberrypi/linux/wiki/How-to-boot-using-device-tree#wiki-Configuration

I've been waiting over 3 months now for device tree support to be added to the GPU-based bootloader and it still hasn't appeared.

Simon Arlott

Ah yes, you are correct sir.

Are the attributes that are currently set by fdtput'ing on the dtb the ones you want to get from the bootloader? Or are there others?

I guess another way to say it is I'm interested in getting as much of this code as we can into mainline as we can before it bitrots (which can happen fast in on the ARM side I think). We can make changes as the proprietary bits catch up.

--
Seth

Honestly, I extracted most of this patch about 3 months ago, and don't remember exactly which of the branches it was based on. Looking at rpi-split, the code could just as well have come from there, so I'll reword the commit description to mention that branch instead.

Sorry Simon, I thought the device tree support was complete, apart from requiring the command line in the device tree file to be padded with spaces.
I didn't realise it was holding anything up. I can look into this - was there anything else missing?

(hijacking the thread a little; sorry)

Popcornmix, I notice that a number of commits in Simon's repo are Signed-off-by yourself. However, those S-o-b tags use the alias "popcornmix" rather than your real name, and hence aren't considered valid by upstream. It'd be great if you could give your permission to Simon to rebase his branch and update all those tags with your real name, or give others permission to rewrite your existing S-o-b tags with your real name when taking those patches and sending them upstream.

Thanks.

No problem. Permission is granted to change the alias popcornmix to Dom Cobley.

Mainly because not stripping it down would be a huge patch or set of patches to review at once. The smaller and more basic we start, the easier it is to get reviewed/applied etc., and then build on incrementally.