Add support for generic BCM SoC chipsets
Subsystems (5)
PATCH 1/1 Add support for generic BCM SoC chipsets
In order to start upstreaming Broadcom SoC support, create a starting hierarchy, arch and dts files.
The first support SoC family that is planned is the
BCM281XX (BCM28145/28150/28155) family of dual A9 mobile SoC cores
This code is just the skeleton code for get the machine upstreamed. It has been made MULTIPLATFORM compatible.
Next steps
----------
Upstream a basic set of drivers - sufficient for a console boot to ramdisk. These will includer timer, gpio, i2c drivers. After this basic set, we will proceed with a more comprehensive set of drivers for the 281XX SoC family.
--- arch/arm/Kconfig | 2 + arch/arm/Makefile | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/capri-brt.dts | 32 +++++++++++ arch/arm/boot/dts/capri.dtsi | 50 +++++++++++++++++ arch/arm/configs/bcm_defconfig | 114 +++++++++++++++++++++++++++++++++++++++ arch/arm/mach-bcm/Kconfig | 18 +++++++ arch/arm/mach-bcm/Makefile | 13 +++++ arch/arm/mach-bcm/board_bcm.c | 66 +++++++++++++++++++++++ 9 files changed, 297 insertions(+) create mode 100644 arch/arm/boot/dts/capri-brt.dts create mode 100644 arch/arm/boot/dts/capri.dtsi create mode 100644 arch/arm/configs/bcm_defconfig create mode 100644 arch/arm/mach-bcm/Kconfig create mode 100644 arch/arm/mach-bcm/Makefile create mode 100644 arch/arm/mach-bcm/board_bcm.c
arch/arm/Kconfig +2 -0
@@ -1022,6 +1022,8 @@ source "arch/arm/mach-mvebu/Kconfig" source "arch/arm/mach-at91/Kconfig" +source "arch/arm/mach-bcm/Kconfig" + source "arch/arm/mach-clps711x/Kconfig" source "arch/arm/mach-cns3xxx/Kconfig"
arch/arm/Makefile +1 -0
@@ -137,6 +137,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-$(CONFIG_ARCH_BCM2835) += bcm2835 machine-$(CONFIG_ARCH_CLPS711X) += clps711x machine-$(CONFIG_ARCH_CNS3XXX) += cns3xxx
arch/arm/boot/dts/Makefile +1 -0
@@ -17,6 +17,7 @@ dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb \ usb_a9263.dtb \ usb_a9g20.dtb dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb +dtb-$(CONFIG_ARCH_BCM) += capri-brt.dtb dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \ dove-cubox.dtb \ dove-dove-db.dtb
arch/arm/boot/dts/capri-brt.dts new file +32 -0
@@ -0,0 +1,32 @@ +/* + * Copyright (C) 2012 Broadcom Corporation + * + * 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 version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +/dts-v1/; + +/include/ "capri.dtsi" + +/ { + model = "Capri BRT board"; + compatible = "bcm,capri"; + interrupt-parent = <&gic>; + + memory { + device_type = "memory"; + reg = <0x80000000 0x40000000>; /* 1 GB */ + }; + + uart at 3e000000 { + status = "okay"; + }; + +};
arch/arm/boot/dts/capri.dtsi new file +50 -0
50 lines not on this page · raw message
arch/arm/configs/bcm_defconfig new file +114 -0
114 lines not on this page · raw message
arch/arm/mach-bcm/Kconfig new file +18 -0
@@ -0,0 +1,18 @@ +config ARCH_BCM + bool "Broadcom SoC" if ARCH_MULTI_V7 + depends on MMU + select CPU_V7 + select ARM_GIC + select GENERIC_GPIO + select GPIO_BCM + select ARCH_REQUIRE_GPIOLIB + select GENERIC_TIME + select GENERIC_CLOCKEVENTS + select TICK_ONESHOT + select ARM_ERRATA_754322 + select ARM_ERRATA_764369 if SMP + select SPARSE_IRQ + help + This enables support for system based on Broadcom SoCs. + It currently supports BCM28145/28150/28155 chips. +
arch/arm/mach-bcm/Makefile new file +13 -0
@@ -0,0 +1,13 @@ +# +# Copyright (C) 2012 Broadcom Corporation +# +# 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 version 2. +# +# This program is distributed "as is" WITHOUT ANY WARRANTY of any +# kind, whether express or implied; without even the implied warranty +# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +obj-$(CONFIG_ARCH_BCM) := board_bcm.o
arch/arm/mach-bcm/board_bcm.c new file +66 -0
66 lines not on this page · raw message
Signature · 1 line
1.7.9.5
PATCH 1/1 Add support for generic BCM SoC chipsets
Quoted 6 lines · Christian Daudt
In order to start upstreaming Broadcom SoC support, create a starting hierarchy, arch and dts files.
The first support SoC family that is planned is the
BCM281XX (BCM28145/28150/28155) family of dual A9 mobile SoC cores
This code is just the skeleton code for get the machine upstreamed. It has been made MULTIPLATFORM compatible.
Christian,
Is the intent for this to support other BCM SoCs in the future, such as the bcm2835 in the Raspberry Pi, and the mach-bcm476x which Domenico Andreoli recently sent patches for? It'd be awesome if Broadcom could provide MMC and USB drivers for the bcm2835 for example.
Quoted 2 lines
arch/arm/boot/dts/capri-brt.dts | 32 +++++++++++ arch/arm/boot/dts/capri.dtsi | 50 +++++++++++++++++
What does the name "capri" refer to? I assume it's a code-name for the SoC/series. My inclination is that naming those files bcm28145.dtsi and bcm28145-brt.dts (or 28150/28155 as appropriate) might be a little more obvious to people unfamiliar with the code-names.
arch/arm/boot/dts/capri-brt.dts line 20
Quoted 5 lines
arch/arm/boot/dts/capri-brt.dts +3
-0+/ { + model = "Capri BRT board"; + compatible = "bcm,capri";
The individual board file's compatible property should contain both a board-specific value and the generic SoC value. This allows the SoC support in the kernel to match on the generic SoC compatible value, yet still allow the kernel to match the board-specific value in case any quirks are required. For example,
compatible = "bcm,brt", "bcm,capri";
(assuming that "brt" is the full board name)
arch/arm/boot/dts/capri-brt.dts
Quoted 1 line
arch/arm/boot/dts/capri-brt.dts +1
-0+ interrupt-parent = <&gic>;
That's already in capri.dtsi; there's no advantage to repeating it.
arch/arm/boot/dts/capri-brt.dts line 24
Quoted 2 lines
arch/arm/boot/dts/capri-brt.dts +2
-0+ memory { + device_type = "memory";
That property already exists in skeleton.dtsi, which is included via capri.dtsi.
arch/arm/boot/dts/capri.dtsi line 26
Quoted 4 lines
arch/arm/boot/dts/capri.dtsi +2
-0+ gic: interrupt-controller at 3ff00100 { + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
The commit description says it's an A9 not an A15.
arch/arm/boot/dts/capri.dtsi line 35
Quoted 2 lines
arch/arm/boot/dts/capri.dtsi +2
-0+ uart at 3e000000 { + compatible = "snps,dw-apb-uart";
You probably want to include SoC-specific compatible values for all the IP blocks too.
There need to be device tree bindings written to describe to contents of all these device-tree files; see Documentation/devicetree/bindings/.
Quoted 6 lines
arch/arm/mach-bcm/Kconfig +4
-0+config ARCH_BCM + bool "Broadcom SoC" if ARCH_MULTI_V7 + depends on MMU + select CPU_V7
arch/arm/mach-bcm/Kconfig line 14
Quoted 10 lines
arch/arm/mach-bcm/Kconfig +10
-0+ select ARM_GIC + select GENERIC_GPIO + select GPIO_BCM + select ARCH_REQUIRE_GPIOLIB + select GENERIC_TIME + select GENERIC_CLOCKEVENTS + select TICK_ONESHOT + select ARM_ERRATA_754322 + select ARM_ERRATA_764369 if SMP + select SPARSE_IRQ
Those select statements should be alphabetically sorted.
arch/arm/mach-bcm/board_bcm.c
Quoted 8 lines
arch/arm/mach-bcm/board_bcm.c +5
-0+ + + + +
Nit: A couple of instances of multiple newlines, but not a big deal.
PATCH 1/1 Add support for generic BCM SoC chipsets
Hi Christian,
Quoted 4 lines · Stephen Warren
Quoted 3 lines · Christian Daudt
In order to start upstreaming Broadcom SoC support, create a starting hierarchy, arch and dts files.
Glad to know that Broadcom is interested in mainline :)
Quoted 9 lines
Quoted 4 lines
The first support SoC family that is planned is the
BCM281XX (BCM28145/28150/28155) family of dual A9 mobile SoC cores
This code is just the skeleton code for get the machine upstreamed. It has been made MULTIPLATFORM compatible.Is the intent for this to support other BCM SoCs in the future, such as the bcm2835 in the Raspberry Pi, and the mach-bcm476x which Domenico Andreoli recently sent patches for? It'd be awesome if Broadcom could provide MMC and USB drivers for the bcm2835 for example.
I'd love to see published some more documentation as well.
Regards,
Domenico
PATCH 1/1 Add support for generic BCM SoC chipsets
In reply to Stephen WarrenQuoted 7 lines · Stephen Warren
Quoted 6 lines · Christian Daudt
In order to start upstreaming Broadcom SoC support, create a starting hierarchy, arch and dts files.
The first support SoC family that is planned is the
BCM281XX (BCM28145/28150/28155) family of dual A9 mobile SoC cores
This code is just the skeleton code for get the machine upstreamed. It has been made MULTIPLATFORM compatible.
Quoted 6 lines
Christian,
Is the intent for this to support other BCM SoCs in the future, such as the bcm2835 in the Raspberry Pi, and the mach-bcm476x which Domenico Andreoli recently sent patches for? It'd be awesome if Broadcom could provide MMC and USB drivers for the bcm2835 for example.
Yes and no :) The intent is to support other BCM SoCs in the future, but Broadcom has a fair number of ARM based SoCs. My primary focus is on the ones from my group within Broadcom (mobile SoCs), but the plan is to bring in others as feasible, and collaborate with other upstreaming work being done for BCM SoCs.
As for bcm2835 MMC and USB, we will be upstreaming MMC and USB
bcm281xx as part of this effort and while I haven't checked the bcm2835 guts (it comes from a different team within Broadcom) I suspect it might share the same IP blocks, which would make it fairly easy to extend our work to add 2835 support. Stay tuned !
Quoted 6 lines
Quoted 2 lines
arch/arm/boot/dts/capri-brt.dts | 32 +++++++++++ arch/arm/boot/dts/capri.dtsi | 50 +++++++++++++++++What does the name "capri" refer to? I assume it's a code-name for the SoC/series. My inclination is that naming those files
bcm28145.dtsiandbcm28145-brt.dts(or 28150/28155 as appropriate) might be a little more obvious to people unfamiliar with the code-names.
Yes, capri is a code name. I've gone back and forth on this one. I think I'll change it to bcm281xx.dtsi and bcm28160-brt.dts, which then refers to the family for the dtsi and the specific chip for the dts.
Quoted 10 lines
arch/arm/boot/dts/capri-brt.dts line 20
Quoted 4 lines
arch/arm/boot/dts/capri-brt.dts +3
-0+/ { + model = "Capri BRT board"; + compatible = "bcm,capri";The individual board file's compatible property should contain both a board-specific value and the generic SoC value. This allows the SoC support in the kernel to match on the generic SoC compatible value, yet still allow the kernel to match the board-specific value in case any quirks are required. For example,
Quoted 3 lines
compatible = "bcm,brt", "bcm,capri";(assuming that "brt" is the full board name)
I will change this based on the above convention i.e.:
compatible = "bcm, bcm28160-brt", "bcm, bcm281xx";
Quoted 2 lines
arch/arm/boot/dts/capri-brt.dts
Quoted 1 line
arch/arm/boot/dts/capri-brt.dts +1
-0+ interrupt-parent =<&gic>;That's already in
capri.dtsi; there's no advantage to repeating it.
ok, removed.
Quoted 4 lines
arch/arm/boot/dts/capri-brt.dts line 24
Quoted 2 lines
arch/arm/boot/dts/capri-brt.dts +2
-0+ memory { + device_type = "memory";That property already exists in
skeleton.dtsi, which is included viacapri.dtsi.
ok, removed.
Quoted 4 lines
arch/arm/boot/dts/capri.dtsi line 26
Quoted 3 lines
arch/arm/boot/dts/capri.dtsi +2
-0+ gic: interrupt-controller at 3ff00100 { + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";The commit description says it's an A9 not an A15.
changed.
Quoted 4 lines
arch/arm/boot/dts/capri.dtsi line 35
Quoted 2 lines
arch/arm/boot/dts/capri.dtsi +2
-0+ uart at 3e000000 { + compatible = "snps,dw-apb-uart";You probably want to include SoC-specific compatible values for all the IP blocks too.
I don't follow this part. Do you mean to replace that line with something like 'compatible = "snps,sw-apb-uart", "bcm, bcm28x11-uart"' ? If so, I don't think that that is necessary - right now there is nothing BCM specific about this.
Quoted 2 lines
There need to be device tree bindings written to describe to contents of all these device-tree files; see
Documentation/devicetree/bindings/.
Added a bcm281xx description.
Quoted 8 lines
Quoted 8 lines
arch/arm/mach-bcm/Kconfig +7
-0+config ARCH_BCM + bool "Broadcom SoC" if ARCH_MULTI_V7 + depends on MMU + select CPU_V7 + select ARM_GIC + select GENERIC_GPIO + select GPIO_BCM
Quoted 8 lines
arch/arm/mach-bcm/Kconfig line 14
Quoted 7 lines
arch/arm/mach-bcm/Kconfig +7
-0+ select ARCH_REQUIRE_GPIOLIB + select GENERIC_TIME + select GENERIC_CLOCKEVENTS + select TICK_ONESHOT + select ARM_ERRATA_754322 + select ARM_ERRATA_764369 if SMP + select SPARSE_IRQThose select statements should be alphabetically sorted.
done
Quoted 8 lines
arch/arm/mach-bcm/board_bcm.c
Quoted 6 lines
arch/arm/mach-bcm/board_bcm.c +5
-0+ + + + +Nit: A couple of instances of multiple newlines, but not a big deal.
done.
thanks,
csd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121111/a8648aa2/attachment-0001.html>
PATCH 1/1 Add support for generic BCM SoC chipsets
Quoted 9 lines · Christian Daudt
Quoted 7 lines · Stephen Warren
arch/arm/boot/dts/capri.dtsi line 35
Quoted 2 lines · Christian Daudt
arch/arm/boot/dts/capri.dtsi new file +2
-0+ uart at 3e000000 { + compatible = "snps,dw-apb-uart";You probably want to include SoC-specific compatible values for all the IP blocks too.
Quoted 4 lines
I don't follow this part. Do you mean to replace that line with something like 'compatible = "snps,sw-apb-uart", "bcm, bcm28x11-uart"' ? If so, I don't think that that is necessary - right now there is nothing BCM specific about this.
I would expect:
compatible = "bcm,bcm28x11-uart", "snps,sw-apb-uart";
The device-tree convention is for the compatible value to always include a specific representation of the exact instance of the HW first (i.e. "bcm,bcm28x11-uart"), and then also describe any base value that the HW is compatible with, or describes the IP block that was instantiated (i.e. "snps,sw-apb-uart"). While the first more-specific value may not be strictly required to make the code work from the start, it is required so that if in the future it is discovered that the HW needs some unexpected quirk or workaround in the driver, the compatible property (for any old device tree that was loaded onto the HW previously) already includes the required value to indicate the specific HW, and hence allow the workaround to be applied.
PATCH 1/1 Add support for generic BCM SoC chipsets
In reply to Christian DaudtQuoted 1 line · Christian Daudt
On 12-11-08 07:24 PM, Stephen Warren wrote:
...
Quoted 11 lines
Quoted 4 lines
Is the intent for this to support other BCM SoCs in the future, such as the bcm2835 in the Raspberry Pi, and the mach-bcm476x which Domenico Andreoli recently sent patches for? It'd be awesome if Broadcom could provide MMC and USB drivers for the bcm2835 for example.
Yes and no :) The intent is to support other BCM SoCs in the future, but Broadcom has a fair number of ARM based SoCs. My primary focus is on the ones from my group within Broadcom (mobile SoCs), but the plan is to bring in others as feasible, and collaborate with other upstreaming work being done for BCM SoCs.
Quoted 5 lines
As for bcm2835 MMC and USB, we will be upstreaming MMC and USB bcm281xx as part of this effort and while I haven't checked the bcm2835 guts (it comes from a different team within Broadcom) I suspect it might share the same IP blocks, which would make it fairly easy to extend our work to add 2835 support. Stay tuned !
So, the bcm2835/Raspberry Pi port is at the stage where MMC and/or USB drivers would be the next useful thing to upstream. However, in order to use those blocks, we should really get communication with the VideoCore working in order to ensure that power and clocks to those modules are configured and enabled.
This begs a few questions
* Do all/most Broadcom SoCs have a VideoCore.
* If so, does the VC typically have complete control over the clock and power/reset trees? Or, are you planning to control these aspects from Linux on the SoCs you're working on upstreaming? If so, is there publicly accessible documentation for your SoC, and is it possible to release similar docs for the 2835?
* If the VC controls this, how standardized is the communication mechanism with the VC; do all SoCs have the same mailbox HW, use the same format for the messages passed through the mailbox, and for mailbox channels where the message is a pointer to the message buffer, do they use the same format for that message buffer?
I note that the earlier Raspberry Pi firmwares didn't include support for the so-called "property mailbox" channel[1]; it was added in later firmwares. So I assume this is something custom for the Raspberry Pi. That'd be a pity since this message format fixed some nasty issues with the other non-property mailbox messages, at least for power control...
Overall, I'm wondering whether the Raspberry Pi upstreaming efforts should just hold off completely until you've got more of the BCM11351/... stuff upstream and simply add that to the Raspberry Pi DT, or whether this aspect won't be re-usable at all.
If there isn't any commonality now in the VC firmware responsibilities and/or message formats, would it be possible to create some kind of standard interface to the firmware, and builds of the firmware that implement that, for upstreaming purposes?
[1] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface
Thanks for any information!
PATCH 1/1 Add support for generic BCM SoC chipsets
Quoted 18 lines · Stephen Warren
Quoted 1 line · Christian Daudt
On 12-11-08 07:24 PM, Stephen Warren wrote:
...
Quoted 10 lines
Quoted 4 lines
Is the intent for this to support other BCM SoCs in the future, such as the bcm2835 in the Raspberry Pi, and the mach-bcm476x which Domenico Andreoli recently sent patches for? It'd be awesome if Broadcom could provide MMC and USB drivers for the bcm2835 for example.
Yes and no :) The intent is to support other BCM SoCs in the future, but Broadcom has a fair number of ARM based SoCs. My primary focus is on the ones from my group within Broadcom (mobile SoCs), but the plan is to bring in others as feasible, and collaborate with other upstreaming work being done for BCM SoCs.
Quoted 5 lines
As for bcm2835 MMC and USB, we will be upstreaming MMC and USB bcm281xx as part of this effort and while I haven't checked the bcm2835 guts (it comes from a different team within Broadcom) I suspect it might share the same IP blocks, which would make it fairly easy to extend our work to add 2835 support. Stay tuned !
Quoted 5 lines
So, the bcm2835/Raspberry Pi port is at the stage where MMC and/or USB drivers would be the next useful thing to upstream. However, in order to use those blocks, we should really get communication with the VideoCore working in order to ensure that power and clocks to those modules are configured and enabled.
Cool. I've started a rewrite of our sdhci driver for upstreaming.
Quoted 4 lines
This begs a few questions
* Do all/most Broadcom SoCs have a VideoCore.
The mobile ones yes, there are a few different versions of videocore. But I'm pretty sure that the version in bcm2835 is identical or almost identical to the version in the mobile SoCs I'm upstreaming.
Quoted 6 lines
* If so, does the VC typically have complete control over the clock and power/reset trees? Or, are you planning to control these aspects from Linux on the SoCs you're working on upstreaming? If so, is there publicly accessible documentation for your SoC, and is it possible to release similar docs for the 2835?
As far as I know, the bcm2835 design in which the videocore has control over the SoC is unique to that model. No other Broadcom SoCs follow that design - or at least none of the mobile SoCs that I work on. As for documentation, there is no publicly available doc on the soc I'm working on. I don't know the state of the 2835 documentation - that comes from a different group within Broadcom.
Quoted 11 lines
* If the VC controls this, how standardized is the communication mechanism with the VC; do all SoCs have the same mailbox HW, use the same format for the messages passed through the mailbox, and for mailbox channels where the message is a pointer to the message buffer, do they use the same format for that message buffer?
I note that the earlier Raspberry Pi firmwares didn't include support for the so-called "property mailbox" channel[1]; it was added in later firmwares. So I assume this is something custom for the Raspberry Pi. That'd be a pity since this message format fixed some nasty issues with the other non-property mailbox messages, at least for power control...
As I mentioned above, the 2835 architecture does not follow the design used on the mobile SoCs. It is unique as far as I know. The mobile SoCs I'm upstreaming boot from the ARM core and the videcore does, well, video stuff :) My (very vague) understanding of the 2835 is that it boots from videocore, and the videocore retains a number of responsibilities.
Quoted 4 lines
Overall, I'm wondering whether the Raspberry Pi upstreaming efforts should just hold off completely until you've got more of the BCM11351/... stuff upstream and simply add that to the Raspberry Pi DT, or whether this aspect won't be re-usable at all.
It is hard to say at this point what the commonality is - I honestly am not that familiar with the 2835. I do suspect that a number of drivers will be similar in that they start from common IP blocks, but they are connected differently in the different SoCs and thus the drivers won't be identical. But it's just a suspicion at this point.
I have purchased a few Raspberry PIs for my team so that we can
familiarize ourselves a bit more with it though :) I think that once we have a basic working set upstreamed (basic clocks, emmc/sd, gpio, and a couple of others), we can then take a look at the 2835 as to how applicable what we've upstreamed is for it. I can't give you a timeframe for this though so I don't know if you want to wait for it or not.
Quoted 4 lines
If there isn't any commonality now in the VC firmware responsibilities and/or message formats, would it be possible to create some kind of standard interface to the firmware, and builds of the firmware that implement that, for upstreaming purposes?
I'll try to understand better the 2835 in the next few weeks so I can provide more meaningful responses. Maybe it'll be my Christmas reading material...
Cheers,
csd
Quoted 4 lines
[1] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface
Thanks for any information!