Commit graph

26 commits

Author SHA1 Message Date
Alexander Graf
04a993fe11 bcm2835_gpio: Implement GPIOF_FUNC
So far we could only tell the gpio framework that a GPIO was mapped as input or
output, not as alternative function.

This patch adds support for determining whether a function is mapped as
alternative.

Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
2016-09-06 13:18:18 -04:00
Stephen Warren
fe84ebf021 rpi: remove redundant board files
Now that rpi_*defconfig and Kconfig (rather than the config header file)
provide the identity of the build, we don't need to separate config
headers and board directories for each RPi variant. Set CONFIG_SYS_BOARD
and CONFIG_SYS_CONFIG_NAME so that we can get rid of the duplication. This
requires a tiny number of extra ifdefs in the config header.

The only disadvantage of this approach is that the $board/$board_name
environment variables aren't as descriptive as they used to be. This isn't
really an issue because those only exist to allow scripts to create DTB
filenames at runtime. However, the RPi board code already sets $fdtfile to
something more accurate based on FW-reported board ID anyway.

While at it, unify some Kconfig select options, and add a MAINTAINERS
entry for bcm283x too.

Partially-suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-04-11 20:48:23 -04:00
Stephen Warren
158c9c78a5 ARM: rpi: add some missing Kconfig help text
Add notes re: enabling the UART to the RPi 3 32-bit help text. Fully
describe the RPi 3 64-bit board option.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-04-11 12:44:38 -04:00
Stephen Warren
d22a765755 ARM: add Raspberry Pi 3 64-bit config
On all Pis so far, the VC FW provides a short stub to set up the ARM CPU
before entering the kernel (a/k/a U-Boot for us). This feature is not
currently supported by the VC FW when booting in 64-bit mode. However,
this feature will likely appear in the near future, and this U-Boot port
assumes that such a feature is in place. Without that feature, or a
temporary workaround described below, U-Boot will not boot.

Once the VC FW does provide the ARM stub, u-boot.bin built for rpi_3 can
be used drectly as kernel7.img, in the same way as any other RPi port. The
following config.txt is required:

    # Fix mini UART input frequency, and setup/enable up the UART.
    # Without this option, U-Boot will not boot, even if you don't care
    # about the serial console. This option will always be required for
    # all RPi3 use-cases, unless the PL011 UART is used, which is not
    # yet supported by rpi_3* builds of U-Boot.
    enable_uart=1
    # Boot in AArch64 (64-bit) mode.
    # It is possible that a future VC FW will remove the need for this
    # option, instead auto-setting 32-/64-bit mode based on the "kernel"
    # filename present on the SD card.
    arm_control=0x200

Prior to the VC FW providing the ARM boot stub, you can use the following
steps to build an equivalent stub into the U-Boot binary:

git clone https://github.com/swarren/rpi-3-aarch64-demo.git \
    ../rpi-3-aarch64-demo
(cd ../rpi-3-aarch64-demo && ./build.sh)
Build U-Boot for rpi_3 in the usual way
cat ../rpi-3-aarch64-demo/armstub64.bin u-boot.bin > u-boot.bin.stubbed
Use u-boot.bin.stubbed as kernel7.img on the Pi SD card.

In this case, the following additional entries are required in config.txt:

    # Tell the FW to load the kernel image at address 0, the reset vector.
    kernel_old=1

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-04-11 12:44:38 -04:00
Stephen Warren
f031f501ef rpi: BCM2837 and Raspberry Pi 3 32-bit support
The Raspberry Pi 3 contains a BCM2837 SoC. The BCM2837 is a BCM2836 with
the CPU complex swapped out for a quad-core ARMv8. This can operate in 32-
or 64-bit mode. 32-bit mode is the current default selected by the
VideoCore firmware on the Raspberry Pi 3. This patch adds a 32-bit port of
U-Boot for the Raspberry Pi 3.

>From U-Boot's perspective, the only delta between the RPi 2 and RPi 3 is a
change in usage of the SoC UARTs. On all previous Pis, the PL011 was the
only UART in use. The Raspberry Pi 3 adds a Bluetooth module which uses a
UART to connect to the SoC. By default, the PL011 is used for this purpose
since it has larger FIFOs than the other "mini" UART. However, this can
be configured via the VideoCore firmware's config.txt file. This patch
hard-codes use of the mini UART in the RPi 3 port. If your system uses the
PL011 UART for the console even on the RPi 3, please use the RPi 2 U-Boot
port instead. A future change might determine which UART to use at
run-time, thus allowing the RPi 2 and RPi 3 (32-bit) ports to be squashed
together.

The mini UART has some limitations. One externally visible issue in the
BCM2837 integration is that the UART divides the SoC's "core clock" to
generate the baud rate. The core clock is typically variable, and under
control of the VideoCore firmware for thermal management reasons. If the
VC FW does modify the core clock rate, UART communication will be
corrupted since the baud rate will vary from the expected value. This was
not an issue for the PL011 UART, since it is fed by a fixed 3MHz clock. To
work around this, the VideoCore firmware can be told not to modify the SoC
core clock. However, the only way this can happen and be thermally safe is
to limit the core clock to a low/minimum frequency. This leaves
performance on the table for use-cases that don't care about a UART
console. Consequently, use of the mini UART console must be explicitly
requested by entering the following line into config.txt:

    enable_uart=1

A recent version of the VC firmware is required to ensure that the mini
UART is fully and correctly initialized by the VC FW; at least
firmware.git 046effa13ebc "firmware: arm_loader: emmc clock depends on
core clock See: https://github.com/raspberrypi/firmware/issues/572".

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-04-01 17:17:42 -04:00
Stephen Warren
95a2ddaea5 ARM: bcm2835: expand Kconfig target descriptions
This adds an explanation of which Raspberry Pi models each target option
supports.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-04-01 17:17:42 -04:00
Stephen Warren
adb91ec72b ARM: bcm2835: move CONFIG_BCM283* to Kconfig
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-04-01 17:17:41 -04:00
Stephen Warren
2b51315894 ARM: bcm2835: fix 64-bit build warning in mbox
Fixes:
arch/arm/mach-bcm283x/mbox.c: In function ‘bcm2835_mbox_call_prop’:
arch/arm/mach-bcm283x/mbox.c:118:48: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
arch/arm/mach-bcm283x/mbox.c:126:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-03-27 09:12:20 -04:00
Stephen Warren
ed7481c7d1 ARM: bcm283x: don't always define CONFIG_BCM2835
Currently, CONFIG_BCM2835 is defined for all BCM283x builds and _BCM2836
is defined when building for that SoC. That means there isn't a single
define that means "exactly BCM2835". This will complicate future patches
where BCM2835-vs-anything-else needs to be determined simply.

Modify the code to define one or the other of CONFIG_BCM2835/BCM2836 so
future patches are simpler.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-03-27 09:12:20 -04:00
Alexander Graf
ccd9d51ede RPi: Enable caches for rpi2
Now that we have support for running with caches enabled in HYP mode,
opt in to that on the Raspberry Pi 2. This brings a significant performance
boost.

Signed-off-by: Alexander Graf <agraf@suse.de>
2016-03-27 09:12:18 -04:00
Lubomir Rintel
757cd149b9 rpi: set board serial number in environment
Gets propagated into the device tree and then into /proc/cpuinfo where
users often expect it.

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
2016-02-24 18:44:12 -05:00
Tom Rini
5b8031ccb4 Add more SPDX-License-Identifier tags
In a number of places we had wordings of the GPL (or LGPL in a few
cases) license text that were split in such a way that it wasn't caught
previously.  Convert all of these to the correct SPDX-License-Identifier
tag.

Signed-off-by: Tom Rini <trini@konsulko.com>
2016-01-19 08:31:21 -05:00
Stephen Warren
dbe6f1eb93 rpi: get rid of BCM2835_BOARD_REV_* macros
There are two numbering schemes for the RPi revision values; old and new
scheme. The values within each scheme overlap. Hence, it doesn't make
sense to have absolute/global names for the revision IDs. Get rid of the
names and just use the raw revision/type values to set up the array of
per-revision data.

This change makes most sense when coupled with the next change. However,
it's split out so that the mechanical cut/paste is separate from the
logic changes for easier review and problem bisection.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-12-05 18:22:35 -05:00
Lubomir Rintel
79ad5cef15 ARM: rpi: add another revision of Raspberry Pi A+
Seen this one in the wild. Is labelled "Raspberry Pi Model A+ V1.1,
(C) Raspberry Pi 2014". A standard A+ board, much like the one with
version 0x12, didn't notice any differencies.

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2015-10-19 08:12:25 +02:00
Alexander Stein
4342557fad arm/mach-bcm283x/mbox: Flush and invalidate dcache when using fw mailbox
When using dcache the setup data for the mailbox must be actually written
into memory before calling into firmware. Thus flush and invalidate the
memory.

Signed-off-by: Alexander Stein <alexanders83@web.de>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
2015-08-12 20:47:42 -04:00
Joe Hershberger
c9bb942e2f Move default y configs out of arch/board Kconfig
Some archs/boards specify their own default by pre-defining the config
which causes the Kconfig system to mix up the order of the configs in
the defconfigs... This will cause merge pain if allowed to proliferate.

Remove the configs that behave this way from the archs.

A few configs still remain, but that is because they only exist as
defaults and do not have a proper Kconfig entry. Those appear to be:

SPIFLASH
DISPLAY_BOARDINFO

Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
[trini: rastaban, am43xx_evm_usbhost_boot, am43xx_evm_ethboot updates,
drop DM_USB from MSI_Primo81 as USB_MUSB_SUNXI isn't converted yet to DM]
Signed-off-by: Tom Rini <trini@konsulko.com>
2015-06-25 22:17:55 -04:00
Marek Vasut
e390bd5ed0 ARM: bcm283x: Switch to generic timer
Switch to generic timer implementation from lib/time.c .
This also fixes a signed overflow which was in __udelay()
implementation.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tyler Baker <tyler.baker@linaro.org>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
2015-05-28 08:18:23 -04:00
Marek Vasut
25a63f5b90 ARM: bcm283x: Reorder timer.h
Reorder the timer.h file so it can be included from board config file.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tyler Baker <tyler.baker@linaro.org>
2015-05-28 08:18:23 -04:00
Marek Vasut
be72355636 ARM: bcm283x: Repair wdog.h
Trivially fix the include check in wdog.h.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tyler Baker <tyler.baker@linaro.org>
2015-05-28 08:18:22 -04:00
Joe Hershberger
a26cd04920 arch: Make board selection choices optional
By making the board selections optional, every defconfig will include
the board selection when running savedefconfig so if a new board is
added to the top of the list of choices the former top's defconfig will
still be correct.

Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tom Rini <trini@konsulko.com>
2015-05-12 18:10:02 -04:00
Masahiro Yamada
58d423b88e dm: select CONFIG_DM* options
As mentioned in the previous commit, adding default values in each
Kconfig causes problems because it does not co-exist with the
"depends on" syntax.  (Please note this is not a bug of Kconfig.)
We should not do so unless we have a special reason.  Actually,
for CONFIG_DM*, we have no good reason to do so.

Generally, CONFIG_DM is not a user-configurable option.  Once we
convert a driver into Driver Model, the board only works with Driver
Model, i.e. CONFIG_DM must be always enabled for that board.
So, using "select DM" is more suitable rather than allowing users to
modify it.  Another good thing is, Kconfig warns unmet dependencies
for "select" syntax, so we easily notice bugs.

Actually, CONFIG_DM and other related options have been added
without consistency: some into arch/*/Kconfig, some into
board/*/Kconfig, and some into configs/*_defconfig.

This commit prefers "select" and cleans up the following issues.

[1] Never use "CONFIG_DM=n" in defconfig files

It is really rare to add "CONFIG_FOO=n" to disable CONFIG options.
It is more common to use "# CONFIG_FOO is not set".  But here, we
do not even have to do it.
Less than half of OMAP3 boards have been converted to Driver Model.
Adding the default values to arch/arm/cpu/armv7/omap3/Kconfig is
weird.  Instead, add "select DM" only to appropriate boards, which
eventually eliminates "CONFIG_DM=n", etc.

[2] Delete redundant CONFIGs

Sandbox sets CONFIG_DM in arch/sandbox/Kconfig and defines it again
in configs/sandbox_defconfig.
Likewise, OMAP3 sets CONFIG_DM arch/arm/cpu/armv7/omap3/Kconfig and
defines it also in omap3_beagle_defconfig and devkit8000_defconfig.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-04-18 11:11:30 -06:00
Stephen Warren
122426d46e ARM: bcm2835: use phys_to_bus() for mbox
When we communicate with the VideoCore to perform property mailbox
transactions, that is a DMA operation as far as the property buffer
is concerned. Use phys_to_bus() on that buffer.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
79340db7f1 ARM: bcm2835: implement phys_to_bus/bus_to_phys
The BCM283[56] contain both a L1 and L2 cache between the GPU (a/k/a
VideoCore CPU?) and DRAM. DMA-capable peripherals can also optionally
access DRAM via this same  L2 cache (although they always bypass the L1
cache). Peripherals select whether to use or bypass the cache via the
top two bits of the bus address.

An IOMMU exists between the ARM CPU and the rest of the system. This
controls whether the ARM CPU's accesses use or bypass the L1 and/or L2
cache. This IOMMU is configured/controlled exclusively by the VideoCore
CPU.

In order for DRAM accesses made by the ARM core to be coherent with
accesses made by other DMA peripherals, we must program a bus address
into those peripherals that causes the peripheral's accesses to use the
same set of caches that the ARM core's accesses will use.

On the RPi1, the VideoCore firmware sets up the IOMMU to enable use of
the L2 cache. This corresponds to addresses based at 0x40000000.

On the RPi2, the VideoCore firmware sets up the IOMMU to disable use of
the L2 cache. This corresponds to addresses based at 0xc0000000.

This patch implements U-Boot's phys_to_bus/bus_to_phys APIs according
to those rules.

For full details of this setup, please see Dom Cobley's description at:
http://lists.denx.de/pipermail/u-boot/2015-March/208201.html
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/215038
https://www.mail-archive.com/u-boot@lists.denx.de/msg166568.html

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
787affb41b ARM: rpi: add a couple more revision IDs
According to Gordon Henderson's WiringPi library, there are some more
Pi revision IDs out there. Add support for them.

http://git.drogon.net/?p=wiringPi;a=blob_plain;f=wiringPi/wiringPi.c;hb=5edd177112c99416f68ba3e8c6c4db6ed942e796

At least ID 0x13 is out in the wild:

Reported-by: Chee-Yang Chau <cychau@gmail.com>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-13 08:48:36 -04:00
Masahiro Yamada
d6c418e4b8 ARM: bcm283x: move SoC headers to mach-bcm283x/include/mach
Move arch/arm/include/asm/arch-bcm283x/*
  -> arch/arm/mach-bcm283x/include/mach/*

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
2015-03-28 09:03:09 -04:00
Masahiro Yamada
ddf6bd4876 ARM: bcm283x: merge BCM2835/BCM2836 directories into mach-bcm283x
BCM2835 (used on Raspberry Pi) and BCM2836 (used on Raspberry Pi 2)
are similar enough.  One of the biggest differences is the ARM
processor.  It is reasonable to collect the source files into a
single place, arch/arm/mach-bcm283x/.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
2015-03-28 09:03:09 -04:00