P2371-0000 is a P2581 or P2530 CPU board married to a P2595 I/O
board. The combination contains SoC, DRAM, eMMC, SD card slot,
HDMI, USB micro-B port, Ethernet via USB3, USB3 host port, SATA,
a GPIO expansion header, and an analog audio jack.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NTom Warren <twarren@nvidia.com>

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>

CONFIG_MAX77620_POWER isn't used anywhere. Don't define it in p2571.h.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
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>

Add a comment block to the top of each generated Tegra pinmux header file
indicating that the file was auto-generated, should not be manually
edited, and with a pointer to the tool and command used to generate it.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
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>

Removed NS16550_COM1 #define, not used since there's no SPL for T210
Also changed the number of USB controllers to 1 as only USBD is used.
Signed-off-by: NTom Warren <twarren@nvidia.com>

All T114+ Tegra boards should be using the Kconfig
TEGRA114_SPI switch. Remove it from include/config
and put it into defconfig. Also removed unused
TEGRA114_SPI_CTRLS from T114+ configs.

All Tegra SoCs build OK with this change.
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>

The tegra-common-usb-gadget.h include was causing
some build problems in ci_udc.c with a 64-bit gcc
in an earlier version of the T210 patches, but it
is working fine now, so restore it.
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

This was done in the 32-bit AVP loader (SPL) but is
board-specific so should be moved to the CPU portion.
Signed-off-by: NTom Warren <twarren@nvidia.com>
Acked-by: NStephen Warren <swarren@nvidia.com>

This config option isn't used anywhere at all. Remove all places that
define/enable the option.
Signed-off-by: NStephen Warren <swarren@nvidia.com>

Document the development flow on figuring out PIRQ information
during the U-Boot porting.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Remove DEBUG in drivers/pci/pci_compat.c.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The code in question polls an USB port status via USB_REQ_GET_STATUS
to determine whether there is a device on the port or not. The way to
figure that out is to check two bits. Those are wPortChange[0] and
wPortStatus[0].

The wPortChange[0] indicates whether some kind of a connection status
change happened on a port (a device was plugged or unplugged). The
wPortStatus[0] bit indicates the status of the connection (plugged or
unplugged).

The current code tests whether wPortChange[0] == wPortStatus[0] and
if that's the case, considers the loop polling for the presence of a
USB device on port finished.

This works for most USB sticks, since they come up really quickly and
trigger the USB port change detection before the first iteration of the
detection loop happens. Thus, both wPortChange[0] and wPortStatus[0]
are set to 1 and thus equal. The loop is existed in it's first iteration
and the stick is detected correctly.

The problem is with some obscure USB sticks, which take some time before
they pop up on the bus after the port was enabled. In this case, both
the wPortChange[0] and wPortStatus[0] are 0. They are equal again, so
the loop again exits in the first iteration, but this is incorrect, as
such USB stick didn't have the opportunity to get detected on the bus.

Rework the code such, that it checks for wPortChange[0] first to test
if any connection change happened at all. If no change occured, keep
polling. If a change did occur, test the wPortStatus[0] to see there is
some device present on the port and only if this is the case, break out
of the polling loop.

This patch also trims down the duration of the polling loop from 10s
per port to 1s per port. This is still annoyingly long, but there is
no better option in case of U-Boot unfortunatelly. This change will
most likely increase the duration of 'usb start' on some platforms,
but this is needed to fix a bug.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Hans de Goede <hdegoede@redhat.com>

This patch fixes operation of our on-board AX88772B chip without EEPROM
but with a ethaddr coming from the regular U-Boot environment. This is
a forward port of some remaining parts initially implemented by
Antmicro.
Signed-off-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: NMarek Vasut <marex@denx.de>

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

usb_stor_reset is only defined when USB storage support is enabled, thus the
function is not declared when such support is missing.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>

This adds some config options to the sunxi-common config to enable the USB
download gadget and the fastboot and USB mass storage functions.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>

Currently, the second use of a gadget will fail, while the first one works.

Forcing the EP0 at every enable fix this issue.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

Now that some things were updated in Kconfig, they should be reflected on the
sunxi-common config too.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>

Now that the musb-new driver has a Kconfig, we can move Kconfig options to
enable controllers to it, so that it's easier in e.g. menuconfig.

In addition, this allows declaring support for USB_MUSB_HOST/GADGET in
defconfigs instead of the USB_MUSB_SUNXI controller, that will get selected
automatically when needed.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>

Having MUSB_HOST and MUSB_GADGET in Kconfig allows more flexibility with regard
to what Kconfig options to enable, such as USB_STORAGE or USB_KEYBOARD.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>

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>

There is no particular reason why the USB Kconfig option should be specific to
host mode. In prevision of adding MUSB host and gadget to Kconfig, this moves
the title and help message of the USB Kconfig option to a more generic format.

Adding comments to the usb Kconfig allows for a better separation and more
readability in generated configs and in menuconfig.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>

The USB_ARCH_HAS_HCD currently serves no purpose and adds some confusion to the
required Kconfig options that are required to have USB support.

Dropping it makes things easier and doesn't break anything, since it was unused
anyways.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>

This patch makes the dwc2 controller like ehci / ohci / xhci controllers
by calling the board_usb_init() function from usb_lowlevel_init.

This can then be implemented by specific platforms to initialise
their USB hardware (phys / clocks etc).
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>

Add some documentation on the EFI implementation in U-Boot.
Signed-off-by: NBen Stoltz <stoltz@google.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

We cannot use this driver when running from EFI as we have no direct hardware
access. In fact coreboot uses a different driver which uses tables provided
by coreboot. So far it does not seem possible to use a normal video driver
when booting from EFI.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NAnatolij Gustschin <agust@denx.de>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

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 memory map is passed from the stub to U-Boot in a table. Add a
command to display it in a vaguely readable fashion.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested on QEMU
Tested-by: NBin Meng <bmeng.cn@gmail.com>

The EFI stub can pass a table to U-Boot with information about the memory map
Potentially other things will follow. Add a way to access this table.
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>