u-boot.git/board/raspberrypi, branch v2016.09

serial: bcm283x_mu: Detect disabled serial device

2016-09-06T17:18:19+00:00

On the raspberry pi, you can disable the serial port to gain dynamic frequency
scaling which can get handy at times.

However, in such a configuration the serial controller gets its rx queue filled
up with zero bytes which then happily get transmitted on to whoever calls
getc() today.

This patch adds detection logic for that case by checking whether the RX pin is
mapped to GPIO15 and disables the mini uart if it is not mapped properly.

That way we can leave the driver enabled in the tree and can determine during
runtime whether serial is usable or not, having a single binary that allows for
uart and non-uart operation.

Signed-off-by: Alexander Graf 
Acked-by: Stephen Warren 
Reviewed-by: Simon Glass

armv8: mmu: Add support of non-identical mapping

2016-07-15T16:01:43+00:00

Introduce virtual and physical addresses in the mapping table. This change
have no impact on existing boards because they all use idential mapping.

Signed-off-by: York Sun

rpi: remove redundant board files

2016-04-12T00:48:23+00:00

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 
Signed-off-by: Stephen Warren 
Reviewed-by: Tom Rini

ARM: add Raspberry Pi 3 64-bit config

2016-04-11T16:44:38+00:00

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 
Reviewed-by: Tom Rini

rpi: BCM2837 and Raspberry Pi 3 32-bit support

2016-04-01T21:17:42+00:00

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 
Reviewed-by: Tom Rini

rpi: add Raspberry Pi 3 board ID

2016-04-01T21:17:42+00:00

This allows U-Boot to known the name of the board.

The existing rpi_2_defconfig can operate correctly on the Raspberry Pi 3
in 32-bit mode /if/ you have configured the firmware to use the PL011 UART
as the console UART (the default is the mini UART). This requires two
things:
a) config.txt should contain dtoverlay=pi3-miniuart-bt
b) You should run the following to tell the VC FW to process DT when
booting, and copy u-boot.bin.img (rather than u-boot.bin) to the SD card
as the kernel image:

   path/to/kernel/scripts/mkknlimg --dtok u-boot.bin u-boot.bin.img

This works as of firmware.git commit 046effa13ebc "firmware: arm_loader:
emmc clock depends on core clock See:
https://github.com/raspberrypi/firmware/issues/572".

Signed-off-by: Stephen Warren 
Reviewed-by: Tom Rini

rpi: use constant "unknown board" DT filename

2016-04-01T21:17:42+00:00

To simplify support for new SoCs, just use a constant filename
for the unknown case. In practice this case shouldn't be hit anyway, so
the filename isn't relevant, and certainly doesn't need to differentiate
between SoCs. If a user has an as-yet-unknown board, they can override
this value in the environment anyway.

Signed-off-by: Stephen Warren 
Reviewed-by: Tom Rini

ARM: bcm283x: don't always define CONFIG_BCM2835

2016-03-27T13:12:20+00:00

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 
Reviewed-by: Tom Rini

serial: pl01x: Add support for devices with the rate pre-configured.

2016-03-22T16:16:12+00:00

For Raspberry Pi, we had the input clock rate to the pl011 fixed in
the rpi.c file, but it may be changed by firmware due to user changes
to config.txt.  Since the firmware always sets up the uart (default
115200 output unless the user changes it), we can just skip our own
uart init to simplify the boot process and more reliably get serial
output.

Signed-off-by: Eric Anholt 
Reviewed-by: Tom Rini 
Tested-by: Stephen Warren

rpi: set board serial number in environment

2016-02-24T23:44:12+00:00

Gets propagated into the device tree and then into /proc/cpuinfo where
users often expect it.

Signed-off-by: Lubomir Rintel 
Tested-by: Stephen Warren 
Reviewed-by: Stephen Warren