| Message ID | 1346908038-22421-1-git-send-email-swarren@wwwdotorg.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thursday 06 September 2012, Stephen Warren wrote: > 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. Very nice! > --- > 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. ok > 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? 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. > * 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? 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. > * 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? The only requirement is that it's inside of the vmalloc area described in Documentation/arm/memory.txt. 0xf0000000 is fine here. > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 88ff698..3c11dce 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -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 All the good things are there, but normally one does not select WATCHDOG here. > +CONFIG_SERIAL_8250=y > +CONFIG_SERIAL_8250_CONSOLE=y > +CONFIG_SERIAL_8250_NR_UARTS=48 > +CONFIG_SERIAL_8250_RUNTIME_UARTS=32 > +CONFIG_SERIAL_8250_EXTENDED=y > +CONFIG_SERIAL_8250_MANY_PORTS=y > +CONFIG_SERIAL_8250_SHARE_IRQ=y > +CONFIG_SERIAL_AMBA_PL010=y > +CONFIG_SERIAL_AMBA_PL010_CONSOLE=y > +CONFIG_SERIAL_AMBA_PL011=y > +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y All three kinds of serial ports really? > diff --git a/arch/arm/mach-bcm2708/common.c b/arch/arm/mach-bcm2708/common.c > new file mode 100644 > index 0000000..85f19aa3 > --- /dev/null > +++ b/arch/arm/mach-bcm2708/common.c I think when this is the only file, we probably want to name this one bcm2708.c, same as the platform. > diff --git a/arch/arm/mach-bcm2708/include/mach/hardware.h b/arch/arm/mach-bcm2708/include/mach/hardware.h > new file mode 100644 > index 0000000..2b15d0b > --- /dev/null > +++ b/arch/arm/mach-bcm2708/include/mach/hardware.h No longer required. > diff --git a/arch/arm/mach-bcm2708/include/mach/timex.h b/arch/arm/mach-bcm2708/include/mach/timex.h > new file mode 100644 > index 0000000..ca67219 > --- /dev/null > +++ b/arch/arm/mach-bcm2708/include/mach/timex.h Very close to not being required any more, so you probably won't need it in 3.7. Arnd
On Thu, Sep 06, 2012 at 09:04:14AM +0000, Arnd Bergmann wrote: > On Thursday 06 September 2012, Stephen Warren wrote: > > > 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? > > 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. 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
On Thursday 06 September 2012, Domenico Andreoli wrote: > On Thu, Sep 06, 2012 at 09:04:14AM +0000, Arnd Bergmann wrote: > > On Thursday 06 September 2012, Stephen Warren wrote: > > > > > 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? > > > > 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. > > 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). 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 ;-) > 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. 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. > 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. 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
(sorry for the dup Stephen, forgot to reply all :-/) On Thu, Sep 6, 2012 at 12:07 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: > > 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. Great work! I'm glad to see this heading upstream :) > 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. 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
On 06/09/12 17:53, Seth Jennings wrote: > (sorry for the dup Stephen, forgot to reply all :-/) > > On Thu, Sep 6, 2012 at 12:07 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> >> 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. > > Great work! I'm glad to see this heading upstream :) > >> 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. 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... > 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. 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. > 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
On Thu, Sep 6, 2012 at 5:10 PM, Simon Arlott <simon@fire.lp0.eu> wrote: > It has supported graphics for a while: > https://github.com/raspberrypi/linux/wiki/How-to-boot-using-device-tree#wiki-Configuration Ah yes, you are correct sir. > 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. 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
On 09/06/2012 10:53 AM, Seth Jennings wrote: > (sorry for the dup Stephen, forgot to reply all :-/) > > On Thu, Sep 6, 2012 at 12:07 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> >> 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. > > Great work! I'm glad to see this heading upstream :) > >> 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. > > 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? 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.
On 09/06/2012 04:10 PM, Simon Arlott wrote: > On 06/09/12 17:53, Seth Jennings wrote: >> (sorry for the dup Stephen, forgot to reply all :-/) >> >> On Thu, Sep 6, 2012 at 12:07 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: >>> >>> 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. >> >> Great work! I'm glad to see this heading upstream :) >> >>> 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. > > 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... 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.
On 09/06/2012 03:04 AM, Arnd Bergmann wrote: > On Thursday 06 September 2012, Stephen Warren wrote: >> 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. >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> +CONFIG_SERIAL_8250=y >> +CONFIG_SERIAL_8250_CONSOLE=y >> +CONFIG_SERIAL_8250_NR_UARTS=48 >> +CONFIG_SERIAL_8250_RUNTIME_UARTS=32 >> +CONFIG_SERIAL_8250_EXTENDED=y >> +CONFIG_SERIAL_8250_MANY_PORTS=y >> +CONFIG_SERIAL_8250_SHARE_IRQ=y >> +CONFIG_SERIAL_AMBA_PL010=y >> +CONFIG_SERIAL_AMBA_PL010_CONSOLE=y >> +CONFIG_SERIAL_AMBA_PL011=y >> +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y > > All three kinds of serial ports really? 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. >> diff --git a/arch/arm/mach-bcm2708/common.c b/arch/arm/mach-bcm2708/common.c > > I think when this is the only file, we probably want to name this one bcm2708.c, > same as the platform. 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. >> diff --git a/arch/arm/mach-bcm2708/include/mach/timex.h b/arch/arm/mach-bcm2708/include/mach/timex.h > > Very close to not being required any more, so you probably won't need it in 3.7. 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.
On Friday 07 September 2012, Stephen Warren wrote: > >> diff --git a/arch/arm/mach-bcm2708/common.c b/arch/arm/mach-bcm2708/common.c > > > > I think when this is the only file, we probably want to name this one bcm2708.c, > > same as the platform. > > 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. It's not a big thing either way. Highbank and socfpga are also good examples and they use the name of the platform. > >> diff --git a/arch/arm/mach-bcm2708/include/mach/timex.h b/arch/arm/mach-bcm2708/include/mach/timex.h > > > > Very close to not being required any more, so you probably won't need it in 3.7. > > 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. Let's not worry about it for now, it's easy enough to remove later. Arnd
On Thu, Sep 6, 2012 at 11:10 PM, Simon Arlott <simon@fire.lp0.eu> wrote: > 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. 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?
On 09/08/2012 11:12 AM, popcornmix wrote: > On Thu, Sep 6, 2012 at 11:10 PM, Simon Arlott <simon@fire.lp0.eu> wrote: >> 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. > > 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.
On Sat, Sep 8, 2012 at 6:48 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > 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. No problem. Permission is granted to change the alias popcornmix to Dom Cobley.
On Thu, Sep 06, 2012 at 03:46:44PM +0000, Arnd Bergmann wrote: > 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. 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.)
On Sat, Sep 08, 2012 at 10:56:10PM +0100, Russell King - ARM Linux wrote: > On Thu, Sep 06, 2012 at 03:46:44PM +0000, Arnd Bergmann wrote: > > 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. > > 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. 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
On Sat, Sep 8, 2012 at 2:56 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Thu, Sep 06, 2012 at 03:46:44PM +0000, Arnd Bergmann wrote: >> 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. > > 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. 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
On Saturday 08 September 2012 22:56:10 Russell King - ARM Linux wrote: > On Thu, Sep 06, 2012 at 03:46:44PM +0000, Arnd Bergmann wrote: > > 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. > > 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 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 Sunday 09 September 2012 02:30:27 Domenico Andreoli wrote: > On Sat, Sep 08, 2012 at 10:56:10PM +0100, Russell King - ARM Linux wrote: > > On Thu, Sep 06, 2012 at 03:46:44PM +0000, Arnd Bergmann wrote: > > > 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. > > > > 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. > > 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? 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
On Sun, 09 Sep 2012 03:16:54 +0200, Arnd Bergmann <arnd@arndb.de> wrote: <snip> >> 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 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. 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> > * 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. 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
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 88ff698..3c11dce 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -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 diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 30eae87..853c761 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -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 diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts new file mode 100644 index 0000000..7e43197 --- /dev/null +++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts @@ -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>; + }; +}; diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi new file mode 100644 index 0000000..221a49a --- /dev/null +++ b/arch/arm/boot/dts/bcm2835.dtsi @@ -0,0 +1,10 @@ +/include/ "skeleton.dtsi" + +/ { + compatible = "broadcom,bcm2835", "broadcom,bcm2708"; + model = "BCM2835"; + + chosen { + bootargs = "earlyprintk"; /* Set by VideoCore */ + }; +}; diff --git a/arch/arm/configs/bcm2708_defconfig b/arch/arm/configs/bcm2708_defconfig new file mode 100644 index 0000000..55cd103 --- /dev/null +++ b/arch/arm/configs/bcm2708_defconfig @@ -0,0 +1,102 @@ +CONFIG_EXPERIMENTAL=y +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SYSVIPC=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +CONFIG_FHANDLE=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_LOG_BUF_SHIFT=18 +CONFIG_CGROUP_FREEZER=y +CONFIG_CGROUP_DEVICE=y +CONFIG_CPUSETS=y +CONFIG_CGROUP_CPUACCT=y +CONFIG_RESOURCE_COUNTERS=y +CONFIG_CGROUP_PERF=y +CONFIG_CFS_BANDWIDTH=y +CONFIG_RT_GROUP_SCHED=y +CONFIG_NAMESPACES=y +CONFIG_SCHED_AUTOGROUP=y +CONFIG_RELAY=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_RD_BZIP2=y +CONFIG_RD_LZMA=y +CONFIG_RD_XZ=y +CONFIG_RD_LZO=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_KALLSYMS_ALL=y +CONFIG_EMBEDDED=y +# CONFIG_COMPAT_BRK is not set +CONFIG_PROFILING=y +CONFIG_OPROFILE=y +CONFIG_JUMP_LABEL=y +# CONFIG_BLOCK is not set +CONFIG_ARCH_BCM2708=y +CONFIG_PREEMPT_VOLUNTARY=y +CONFIG_COMPACTION=y +CONFIG_KSM=y +CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 +CONFIG_CLEANCACHE=y +CONFIG_SECCOMP=y +CONFIG_CC_STACKPROTECTOR=y +CONFIG_KEXEC=y +CONFIG_CRASH_DUMP=y +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +# CONFIG_SUSPEND is not set +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_STANDALONE is not set +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_SERIO is not set +# CONFIG_VT is not set +# CONFIG_UNIX98_PTYS is not set +# CONFIG_LEGACY_PTYS is not set +# CONFIG_DEVKMEM is not set +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=48 +CONFIG_SERIAL_8250_RUNTIME_UARTS=32 +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_MANY_PORTS=y +CONFIG_SERIAL_8250_SHARE_IRQ=y +CONFIG_SERIAL_AMBA_PL010=y +CONFIG_SERIAL_AMBA_PL010_CONSOLE=y +CONFIG_SERIAL_AMBA_PL011=y +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y +CONFIG_TTY_PRINTK=y +# CONFIG_HW_RANDOM is not set +# CONFIG_HWMON is not set +# CONFIG_USB_SUPPORT is not set +# CONFIG_IOMMU_SUPPORT is not set +# CONFIG_FILE_LOCKING is not set +# CONFIG_DNOTIFY is not set +# CONFIG_INOTIFY_USER is not set +# CONFIG_PROC_FS is not set +# CONFIG_SYSFS is not set +# CONFIG_MISC_FILESYSTEMS is not set +CONFIG_PRINTK_TIME=y +# CONFIG_ENABLE_WARN_DEPRECATED is not set +# CONFIG_ENABLE_MUST_CHECK is not set +CONFIG_UNUSED_SYMBOLS=y +CONFIG_LOCKUP_DETECTOR=y +CONFIG_DEBUG_INFO=y +CONFIG_DEBUG_MEMORY_INIT=y +CONFIG_BOOT_PRINTK_DELAY=y +CONFIG_SCHED_TRACER=y +CONFIG_STACK_TRACER=y +CONFIG_FUNCTION_PROFILER=y +CONFIG_DYNAMIC_DEBUG=y +CONFIG_KGDB=y +CONFIG_KGDB_KDB=y +CONFIG_TEST_KSTRTOX=y +CONFIG_STRICT_DEVMEM=y +CONFIG_DEBUG_LL=y +CONFIG_EARLY_PRINTK=y +# CONFIG_XZ_DEC_X86 is not set +# CONFIG_XZ_DEC_POWERPC is not set +# CONFIG_XZ_DEC_IA64 is not set +# CONFIG_XZ_DEC_ARM is not set +# CONFIG_XZ_DEC_ARMTHUMB is not set +# CONFIG_XZ_DEC_SPARC is not set diff --git a/arch/arm/mach-bcm2708/Makefile b/arch/arm/mach-bcm2708/Makefile new file mode 100644 index 0000000..f95691b --- /dev/null +++ b/arch/arm/mach-bcm2708/Makefile @@ -0,0 +1 @@ +obj-y += common.o diff --git a/arch/arm/mach-bcm2708/Makefile.boot b/arch/arm/mach-bcm2708/Makefile.boot new file mode 100644 index 0000000..0831fd1 --- /dev/null +++ b/arch/arm/mach-bcm2708/Makefile.boot @@ -0,0 +1,5 @@ + zreladdr-y := 0x00008000 +params_phys-y := 0x00000100 +initrd_phys-y := 0x00800000 + +dtb-y += bcm2835-rpi-b.dtb diff --git a/arch/arm/mach-bcm2708/common.c b/arch/arm/mach-bcm2708/common.c new file mode 100644 index 0000000..85f19aa3 --- /dev/null +++ b/arch/arm/mach-bcm2708/common.c @@ -0,0 +1,80 @@ +/* + * 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. + */ + +#include <linux/init.h> +#include <linux/of_platform.h> + +#include <asm/mach/arch.h> +#include <asm/mach/map.h> +#include <asm/mach/time.h> +#include <asm/exception.h> + +#include <mach/bcm2708_soc.h> + +static struct map_desc io_map __initdata = { + .virtual = BCM2708_PERIPH_VIRT, + .pfn = __phys_to_pfn(BCM2708_PERIPH_BASE), + .length = BCM2708_PERIPH_SIZE, + .type = MT_DEVICE +}; + +void __init bcm2708_map_io(void) +{ + iotable_init(&io_map, 1); +} + +void __init bcm2708_init_irq(void) +{ +} + +asmlinkage void __exception_irq_entry bcm2708_handle_irq(struct pt_regs *regs) +{ +} + +void __init bcm2708_init(void) +{ + int ret; + + ret = of_platform_populate(NULL, of_default_bus_match_table, NULL, + NULL); + if (ret) { + pr_err("of_platform_populate failed: %d\n", ret); + BUG(); + } +} + +static void __init bcm2708_timer_init(void) +{ +} + +struct sys_timer bcm2708_timer = { + .init = bcm2708_timer_init +}; + +static const char * const bcm2708_compat[] = { + "broadcom,bcm2708", + NULL +}; + +DT_MACHINE_START(BCM2708, "BCM2708") + .map_io = bcm2708_map_io, + .init_irq = bcm2708_init_irq, + .handle_irq = bcm2708_handle_irq, + .init_machine = bcm2708_init, + .timer = &bcm2708_timer, + .dt_compat = bcm2708_compat +MACHINE_END diff --git a/arch/arm/mach-bcm2708/include/mach/bcm2708_soc.h b/arch/arm/mach-bcm2708/include/mach/bcm2708_soc.h new file mode 100644 index 0000000..4ddeb4e --- /dev/null +++ b/arch/arm/mach-bcm2708/include/mach/bcm2708_soc.h @@ -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 diff --git a/arch/arm/mach-bcm2708/include/mach/debug-macro.S b/arch/arm/mach-bcm2708/include/mach/debug-macro.S new file mode 100644 index 0000000..ef71e41 --- /dev/null +++ b/arch/arm/mach-bcm2708/include/mach/debug-macro.S @@ -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> diff --git a/arch/arm/mach-bcm2708/include/mach/hardware.h b/arch/arm/mach-bcm2708/include/mach/hardware.h new file mode 100644 index 0000000..2b15d0b --- /dev/null +++ b/arch/arm/mach-bcm2708/include/mach/hardware.h @@ -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 diff --git a/arch/arm/mach-bcm2708/include/mach/timex.h b/arch/arm/mach-bcm2708/include/mach/timex.h new file mode 100644 index 0000000..ca67219 --- /dev/null +++ b/arch/arm/mach-bcm2708/include/mach/timex.h @@ -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 diff --git a/arch/arm/mach-bcm2708/include/mach/uncompress.h b/arch/arm/mach-bcm2708/include/mach/uncompress.h new file mode 100644 index 0000000..0c8fe04 --- /dev/null +++ b/arch/arm/mach-bcm2708/include/mach/uncompress.h @@ -0,0 +1,49 @@ +/* + * Copyright (C) 2012 Stephen Warren + * + * Derived from code: + * Copyright (C) 2010 Broadcom + * Copyright (C) 2003 ARM Limited + * + * 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. + */ + +#include <linux/io.h> +#include <linux/amba/serial.h> +#include <mach/bcm2708_soc.h> + +#define UART_BAUD 115200 +#define UART0_BASE BCM2708_DEBUG_BASE + +#define BCM2708_UART_DR IOMEM(UART0_BASE + UART01x_DR) +#define BCM2708_UART_FR IOMEM(UART0_BASE + UART01x_FR) +#define BCM2708_UART_CR IOMEM(UART0_BASE + UART011_CR) + +static inline void putc(int c) +{ + while (__raw_readl(BCM2708_UART_FR) & UART01x_FR_TXFF) + barrier(); + + __raw_writel(c, BCM2708_UART_DR); +} + +static inline void flush(void) +{ + int fr; + + do { + fr = __raw_readl(BCM2708_UART_FR); + barrier(); + } while ((fr & (UART011_FR_TXFE | UART01x_FR_BUSY)) != UART011_FR_TXFE); +} + +#define arch_decomp_setup() +#define arch_decomp_wdog()
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 <bootc@bootc.net> Simon Arlott <sa.me.uk> [sic] Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> --- 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