First supported chip is APQ8016 (that is compatible with MSM8916).
Drivers in SoC code:
- Reset controller (PSHOLD)
- Clock controller (very simple clock configuration for MMC and UART)

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

This driver supports GPIOs present on PM8916 PMIC.
There are 2 device drivers inside:
- GPIO driver (4 "generic" GPIOs)
- Keypad driver that presents itself as GPIO with 2 inputs (power and reset)

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

This PMIC is connected on SPMI bus so needs SPMI support enabled.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

Support SPMI arbiter on Qualcomm Snapdragon devices.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

This patch adds emulated spmi bus controller with part of
pm8916 pmic on it to sandbox and tests validating SPMI uclass.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Qualcom processors use proprietary bus to talk with PMIC devices -
SPMI (System Power Management Interface).
On wiring level it is similar to I2C, but on protocol level, it's
multi-master and has simple autodetection capabilities.
This commit adds simple uclass that provides bus read/write interface.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

This driver is able to reconfigure OTG controller into HOST mode.
Board can add board-specific initialization as board_prepare_usb().
It requires USB_ULPI_VIEWPORT enabled in board configuration.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
Tested-by: Simon Glass <sjg@chromium.org>

Use definitions from ehci.h instead.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
Tested-by: Simon Glass <sjg@chromium.org>

Some registers of usb_ehci were marked as reserved.
This may be true for some variants of Chipidea USB core, but they have
meaning on other devices.

The following registers were added:
sbusstatus/sbusmode: AHB-related registers
genconfig*: Auxiluary IP core configuration registers.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Tested-by: Simon Glass <sjg@chromium.org>

Most of ehci-fsl header describe USB controller
designed by Chipidea and used by various SoC vendors.

This patch renames it to a generic header: ehci-ci.h
Contents of file are not changed (so it contains several
references to freescale SoCs).

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
Tested-by: Simon Glass <sjg@chromium.org>

Debug printf used '%u' to print size_t variable.
This caused warnings on 64-bit machines.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

ulpi_read and ulpi_write are used to read/write registers via ULPI bus.
Code generates compilation warnings on 64-bit machines where pointer
is cast to u32.

This patch drops all but last 8 bits of register address.
It is possible, because addresses on ULPI bus are 6- or 8-bit.

It is not possible (according to ULPI 1.1 spec) to have more
than 8-bit addressing.

This patch should not cause regressions as all calls to
ulpi_read/write use either structure pointer (@ address 0) or integer
offsets cast to pointer - addresses requested are way below 8-bit range.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>

viewport_addr is address of memory mapped ULPI viewport.
It is used only as argument to readl/writel later
causing compile warnings on 64-bit devices.

This fix changes its type to match pointer size.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>

Move CONFIG_USB_ULPI* from headers to defconfigs for boards that use it.
Also - add CONFIG_USB where necesarry - all boards use it,
but some are not defining it explicitly.

Affected boards:
colibri_t20, harmony, mcx, mt_ventoux, twister,
zynq_(picozed, zc702, zc706, zed, zybo)

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The following options can be now enabled via defconfig:
- CONFIG_USB_ULPI
- CONFIG_USB_ULPI_VIEWPORT
- CONFIG_USB_ULPI_VIEWPORT_OMAP

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>

Some host controllers need addidional initialization after ehci_reset()
In non-dm implementation it is possible to use CONFIG_EHCI_HCD_INIT_AFTER_RESET.
This patch adds similar option to ehci drivers using dm.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

Add support for SD/eMMC controller present on some Qualcomm Snapdragon
devices. This controller implements SDHCI 2.0 interface but requires
vendor-specific initialization.
Driver works in PIO mode as ADMA is not supported by U-Boot (yet).

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

Add support for gpio controllers on Qualcomm Snapdragon devices.
This devices are usually called Top Level Mode Multiplexing in
Qualcomm documentation.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

This driver works in "new" Data Mover UART mode, so
will be compatible with modern Qualcomm chips only.

Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

Enable the TI DP83867 Giga bit phy on the
dra7 rev c board.  The rx and tx internal
delays are need for this board so the usage
of RGMII_ID is required.

Signed-off-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

This moves the sniper board from the lge to lg, in order to match the devicetree
vendor prefix already defined in the kernel.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

With the previous implementation, rebooting without registering a recognized
reboot mode would end up with U-Boot checking for a valid power-on reason, which
might result in the device turning off (e.g. with no USB cable attached and no
buttons pressed).

Since this approach is not viable (breaks reboot in most cases), the validity of
the reboot reason is checked (in turn, by checking that a warm reset happened,
as there is no magic) to detect a reboot and the 'o' char is recognized to
indicate that power-off is required. Still, that might be overridden by the
detection of usual power-on reasons, on purpose.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

With the previous implementation, rebooting without registering a recognized
reboot mode (despite registering the magic) would end up with U-Boot checking
for a valid power-on reason, which might result in the device turning off (e.g.
with no USB cable attached and no buttons pressed).

This was designed to catch reboots that are actually intended to be power-off,
something that old Android kernels do, instead of properly turning the device
off using the TWL4030.

However, since this approach is not viable (breaks reboot in most cases), the
validity of the reboot mode magic is checked to detect a reboot and the 'o' char
is recognized to indicate that power-off is required. Still, that might be
overridden by the detection of usual power-on reasons, on purpose.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

This adds some environment variables for sysboot and devicetree.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

Selecting CONFIG_OF_LIBFDT allows running recent mainline kernels.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

This makes the baudrate for the kernel command line explicit.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

This makes the baudrate for the kernel command line explicit.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

Make sure to call unmap_sysmem() for address allocated by map_sysmem()
before leaving the function; however this patch gives no impact on
the behavior because map_sysmem()/unmap_sysmem() does nothing except
on Sandbox.  Sandbox never runs this code because "booti" is a command
for booting ARM64 kernel image.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>

U-boot for general purpose KS2 devices is loaded to the beginning of the
internal memory (0x0c000000). Secure devices uses this memory and
CONFIG_SYS_TEXT_BASE has to be different for those devices.

This commit make this configurable at build time by giving
CONFIG_SYS_TEXT_BASE as a command line definition to make command.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>

The default board_init_f() implementation performs a call to
board_init_r() as the last step of the sequence. Fix the comment
for this function to reflect the actual execution flow.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>

Given that README.scrapyard shows scrapping of netta boards:

netta2           powerpc     mpc8xx         c51c1c9a    2014-07-07
netta            powerpc     mpc8xx         c51c1c9a    2014-07-07

delete netta example from POST tests.

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

Add exclamation mark to the errmsg, when error and set_default_env.

Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Mario Schuknecht <mario.schuknecht@dresearch-fe.de>
Cc: Vignesh R <vigneshr@ti.com>
Cc: Jagan Teki <jteki@openedev.com>
Cc: Ravi Babu <ravibabu@ti.com>
Cc: York Sun <york.sun@nxp.com>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

We only use 'ofs' in jffs2_sum_scan_sumnode when debugging as it's part
of a dbg_summary call.  Mark this as __maybe_unused.

Signed-off-by: Tom Rini <trini@konsulko.com>

We normally use __weak rather than calling it out directly as an alias.
Update this function to the normal method.

Signed-off-by: Tom Rini <trini@konsulko.com>

Since POST_ALWAYS is defined as:

#define POST_ALWAYS             (POST_NORMAL    | \
                                 POST_SLOWTEST  | \
                                 POST_MANUAL    | \
                                 POST_POWERON   )

there is no need to redundantly bitmask it with POST_MANUAL.

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

POST support for sample lwmon board was removed in commit e5d30786.

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca&gt;B>

In case of #define DEBUG 1 (fordebugging SPL). A bug in
spl_nand_load_image() will be triggered, because it prints
using hw ecc regardless of soft ecc configurations and
initializations.

Signed-off-by: Ahmed Samir <engkhalil86@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

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>

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>