E2220-1170 is a Tegra210 bringup board with onboard SoC, DRAM,
eMMC, SD card slot, HDMI, USB micro-B port, and sockets for various
expansion modules.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

T124/210 requires some specific configuration (VPR setup) to
be performed by the bootloader before the GPU can be used.
For this reason, the GPU node in the device tree is disabled
by default. This patch enables the node if U-boot has performed
VPR configuration.

Boards enabled by this patch are T124's Jetson TK1 and Venice2
and T210's P2571.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Tom Warren <twarren@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

U-boot is responsible for enabling the GPU DT node after all necessary
configuration (VPR setup for T124) is performed. In order to be able to
check whether this configuration has been performed right before booting
the kernel, make it happen during board_init().

Also move VPR configuration into the more generic gpu.c file, which will
also host other GPU-related functions, and let boards specify
individually whether they need VPR setup or not.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Tom Warren <twarren@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

Additionally, ARM64 devices typically run a secure monitor in EL3 and
U-Boot in EL2, and set up some secure RAM carve-outs to contain the EL3
code and data. These carve-outs are located at the top of 32-bit address
space. Restrict U-Boot's RAM usage to well below the location of those
carve-outs. Ideally, we would the secure monitor would inform U-Boot of
exactly which RAM it could use at run-time. However, I'm not sure how to
do that at present (and even if such a mechanism does exist, it would
likely not be generic across all forms of secure monitor).
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

Added PLL variables (dividers mask/shift, lock enable/detect, etc.)
to new pllinfo struct for each Soc/PLL. PLLA/C/D/E/M/P/U/X.

Used pllinfo struct in all clock functions, validated on T210.
Should be equivalent to prior code on T124/114/30/20. Thanks
to Marcel Ziswiler for corrections to the T20/T30 values.
Signed-off-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

Added 38.4MHz/48MHz entries to pll_x_table for CPU PLL. Needs
to be measured - should be close to 700MHz (1.4G/2).

Note that some freqs aren't in the PLLU table in T210 TRM
(13, 26MHz), so I used the 12MHz table entry for them. They
shouldn't be selected since they're not viable T210 OSC freqs.

Since there are now 2 new OSC defines, all tables (pll_x_table,
PLLU) had to increase by two entries, but since 38.4/48MHz are
not viable osc freqs on T20/30/114, etc, they're just set to 0.
Signed-off-by: NTom Warren <twarren@nvidia.com>

CPU board (E2530) has a fan - turn it on via GPIO to keep
the SoC cool.
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

USB_KEYBOARD is now defined in drivers/usb/Kconfig, drop our own duplicate
definition.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

USB-related options are usually prefixed with CONFIG_USB and platform-specific
adaptation for the MUSB controller already have a CONFIG_USB_MUSB prefix, so
this switches all MUSB-related options to a CONFIG_USB_MUSB prefix, for
consistency.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>

Disable a few things which interfere with the EFI init. This allows QEMU to
to boot into EFI, load a U-Boot payload then boot to the U-Boot prompt.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

Disable a few things which interfere with the EFI init. This allows the
Minnowboard MAX to boot into EFI, load a U-Boot payload then boot to the
U-Boot prompt.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

When U-Boot is running from EFI some of the x86 init is replaced with
EFI-specific init. For example, since DRAM has already been set up, we only
need to find it, not init it. Add these functions so that boards can easily
allow booting from EFI if required.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

When U-Boot runs as an EFI payload it needs to avoid setting up the CPU
again. Also U-Boot currently does not handle interrupts for many devices, so
run with interrupts disabled.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

The EFI stub provides information to U-Boot in a table. This includes the
memory map which is needed to decide where to relocate U-Boot. Collect this
information in the early init code and store it in global_data.

Fix up the BIST code at the same time since we don't have it when booting
from EFI and can assume it is 0.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Most EFI implementations use 64-bit. Add a way to build U-Boot as a 64-bit
EFI payload. The payload unpacks a (32-bit) U-Boot and starts it. This can
be enabled for x86 boards at present.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Improvements to how the payload is built:
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

The procedure to drop from 64-bit mode to 32-bit is a bit messy. Add a
function to take care of it. It requires identity-mapped pages and that
the calling code is running below 4GB.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Rather than add these as open-coded values, create an enum with the commonly
used flags.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Add support for building a 32/64-bit EFI stub for x86. This involves
building the startup and relocation code for either i386 or x86_64.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

It is useful to be able to load U-Boot onto a board even if is it already
running EFI. This can allow access to the U-Boot command interface, flexible
booting options and easier development.

The easiest way to do this is to build U-Boot as a binary blob and have an
EFI stub copy it into RAM. Add support for this feature, targeting 32-bit
initially.

Also add a way to detect when U-Boot has been loaded via a stub. This goes
in common.h since it needs to be widely available so that we avoid redoing
initialisation that should be skipped.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Improvements to how the payload is built:
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

Add a linker script and relocation code for building 64-bit EFI
applications. This can be used for the EFI stub.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Improvements to how the payload is built:
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

This code currently requires CONFIG_SYS_TEXT_BASE but this should be
unnecessary. As a first step, remove the build-time limitation and report an
error instead.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

This contains just enough to bring up the serial UART.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

Add support for the efi-x86 board, which supports running U-Boot as an
EFI 32-bit application.
Signed-off-by: NBen Stoltz <stoltz@google.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

Add the required x86 glue code. This includes the initial start-up,
relocation and jumping to efi_main(). We also need to avoid fiddling with
interrupts.
Signed-off-by: NBen Stoltz <stoltz@google.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Bring in this file from Linux 4.1. It supports relocation features specific
to x86.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

When running as an EFI application we must skip relocation. Add support for
this in the x86 relocation code.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Adjust the toolchain flags to build U-Boot as a relocatable shared library,
as required by EFI.
Signed-off-by: NBen Stoltz <stoltz@google.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

When running as an EFI application, U-Boot must request memory from EFI,
and provide access to the boot services U-Boot needs.

Add library code to perform these tasks. This includes efi_main() which is
the entry point from EFI. U-Boot is built as a shared library.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

On x86 the global_data pointer is provided through a somewhat-bizarre and
x86-specific mechanism: the F segment register is set to a pointer to the
start of global_data, so that accesses can use this build-in register.

When running as an EFI application we don't want to mess with the Global
Descriptor Table (GDT) and there is little advantage (in terms of code size)
to doing so.

Allow global_data to be a simple variable in this case.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Fix a typo, remove an unused field and make sure to use existing #define
constants instead of open-coded values.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Some files use global_data but don't declare it. Fix this.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

The GDT works but technically the length is incorrect. Fix this and add a
comment.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

This is now handled by generic U-Boot code so we do not need an x86 version.
It is no-longer called, so remove it.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

These flags now overlap some global ones. Adjust the x86-specific flags to
avoid this. Since this requires a change to the start.S code, add a way for
tools to find the 32-bit cold reset entry point. Previously this was at a
fixed offset.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

We should use these constants where possible.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Fix a typo, improve some comments and add a little more detail in some
cases.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Add PCI IRQ routing information in the board device tree and enable
writing PIRQ routing table and MP table.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Intel Bayley Bay board is a BayTrail based board. Add this board
with existing baytrail fsp support.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This commit adds the microcode blob for BayTrail-I B0 stepping,
CPUID signature 30671h.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

BayTrail FSP Gold4 release adds one UPD parameter to control IGD
enable/disable.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>