There is no justification for this function, especially in exported
form.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add code to detect timeouts when waiting for HW events such as PLL
lock done. Any errors are logged and trigger an error return code.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add the tables defining which pads and mux options exist in the Tegra210
XUSB padctl hardware.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This change simply deletes code from the Tegra210 XUSB padctl driver that
is already present in the common XUSB padctl code. Since all the arrays
in tegra210_socdata are empty, this update may leave the Tegra210 XUSB
padctl driver non-functional at run-time. However, (a) this driver is not
used yet so no regression can be observed and (b) the next commit will
immediately fix this up.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
There are some differences between the Tegra124 and Tegra210 XUSB padctl
code. So far, the common XUSB padctl code only supports Tegra124. Add
some parameters etc. so that it can work for both chips.
This also allows moving Tegra124's process_nodes() into the common file;
something that would have requires edits during the move if done in the
previous commit.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
A fair amount of the XUSB padctl driver will be common between Tegra124
and Tegra210. To avoid cut/paste between the two chips, create a new
file that will contain the common code, and convert the Tegra124 code to
use it. This change doesn't move every last piece of code that can/will be
shared, but rather concentrates on moving code that can be moved with zero
changes, so there are no other diffs mixed in.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This file defines pr_fmt(), so the individual error() calls don't need to
include the prefix in their format strings. Doing so results in duplicate
text in any error messages. Remove the duplication.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
A future patch will soon move some of the XUSB padctl code into a common
file in arch/arm/mach-tegra. Rename the existing dummy XUSB padctl file
to avoid conflicting with that, or being confusing.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Implement the procedure that the TRM mandates to initialize PLLREFE and
PLLE. This makes the PLL actually lock.
Note that this section of the TRM is being cleaned up to remove some
confusion. The set of register accesses in this patch should be final,
although the step numbers/descriptions might still change.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This sets up a fine-grained page table, which is a requirement for
noncached_init() to operate correctly.
MMU setup code currently exists in a number of places:
- A version in the core ARMv8 support code that sets up page tables that
use very large block sizes that CONFIG_SYS_NONCACHED_MEMORY doesn't
support.
- Enhanced versions for fsl-lsch3 and zynmq that set up finer grained
page tables.
Ideally, rather than duplicating the MMU setup code yet again this patch
would instead consolidate all the different routines into the core ARMv8
code so that it supported all use-cases. However, this will require
significant effort since there appear to be a number of discrepancies[1]
between different versions of the code, and between the defines/values by
some copies of the MMU setup code use and the architectural MMU
documentation. Some reverse engineering will be required to determine the
intent of the current code.
[1] For example, in the core ARMv8 MMU setup code, three defines named
TCR_EL[123]_IPS_BITS exist, but only one of them sets the IPS field and
the others set a different field (T1SZ) in the page tables. As far as I
can tell so far, there should be no need to set different values per
exception level nor to modify the T1SZ field at all, since TTBR1 shouldn't
be enabled anyway. Another example is inconsistent values for *_VA_BITS
between the current core ARMv8 MMU setup code and the various SoC-
specific MMU setup code. Another example is that asm/armv8/mmu.h's value
for SECTION_SHIFT doesn't match asm/system.h's MMU_SECTION_SHIFT;
research is needed to determine which code relies on which of those
values and why, and whether fixing the incorrect value will cause any
regression.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
After consulting with some of the SPDX team, the conclusion is that
Makefiles are worth adding SPDX-License-Identifier tags too, and most of
ours have one. This adds tags to ones that lack them and converts a few
that had full (or in one case, very partial) license blobs into the
equivalent tag.
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Enabling a PLL while IDDQ is high. The Linux kernel checks for this
condition and warns about it verbosely, so while this seems to work
fine, fix it up according to the programming guidelines provided in
the Tegra K1 TRM (v02p), Section 5.3.8.1 ("PLLC and PLLC4 Startup
Sequence"). The Tegra114 TRM doesn't contain this information, but
the programming of PLLC is the same on Tegra114 and Tegra124.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Enabling a PLL while IDDQ is high. The Linux kernel checks for this
condition and warns about it verbosely, so while this seems to work
fine, fix it up according to the programming guidelines provided in
the Tegra K1 TRM (v02p), Section 5.3.8.1 ("PLLC and PLLC4 Startup
Sequence").
Reported-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
While clk_m and the oscillator run at the same frequencies on Tegra114
and Tegra124, clk_m is the proper source for the architected timer. On
more recent Tegra generations, Tegra210 and later, both the oscillator
and clk_m can run at different frequencies. clk_m will be divided down
from the oscillator.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
On currently supported SoCs, clk_m always runs at the same frequency as
the oscillator input. However newer SoC generations such as Tegra210 no
longer have that restriction. Prepare for that by separating clk_m from
the oscillator clock and allow SoC code to override the clk_m rate.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
AFAIK, for all PLLs on all Tegra SoCs, the primary PLL output frequency
is (input * m) / (n * p). However, PLLP's primary output (pllP_out0) on
T210 is the VCO output, and divp is not applied. pllP_out2 does have divp
applied. All other pllP_outN are divided down from pllP_out0. We only
support pllP_out0 in U-Boot at the time of writing.
Fix clock_get_rate() to handle this special case.
This corrects the returned rate for PLLP to be 408MHz rather than 204MHz.
In turn, this causes high enough dividers to be calculated for the various
peripheral clocks that feed off of PLLP. Without this, some peripherals
failed to operate correctly. For instance, one of my SD cards worked
perfectly but an older (presumably slower) card could not be read.
Note that prior to commit 722e000ccd "Tegra: PLL: use per-SoC pllinfo
table instead of PLL_DIVM/N/P, etc.", the calculated PLL frequency was
816MHz since the wrong values were being extracted from the PLLP divider
register. This caused overly large peripheral dividers to be calculated,
which while wrong, didn't cause any correctness issues; things simply ran
slower than they could.
Reported-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
P2371-2180 is a P2180 CPU board married to a P2597 I/O board. The
combination contains SoC, DRAM, eMMC, SD card slot, HDMI, USB
micro-B port, Ethernet via USB3, USB3 host port, SATA, PCIe, and
two GPIO expansion headers.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
We have flipped CONFIG_SPL_DISABLE_OF_CONTROL. We have cleansing
devices, $(SPL_) and CONFIG_IS_ENABLED(), so we are ready to clear
away the ugly logic in include/fdtdec.h:
#ifdef CONFIG_OF_CONTROL
# if defined(CONFIG_SPL_BUILD) && !defined(SPL_OF_CONTROL)
# define OF_CONTROL 0
# else
# define OF_CONTROL 1
# endif
#else
# define OF_CONTROL 0
#endif
Now CONFIG_IS_ENABLED(OF_CONTROL) is the substitute. It refers to
CONFIG_OF_CONTROL for U-boot proper and CONFIG_SPL_OF_CONTROL for
SPL.
Also, we no longer have to cancel CONFIG_OF_CONTROL in
include/config_uncmd_spl.h and scripts/Makefile.spl.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
As we discussed a couple of times, negative CONFIG options make our
life difficult; CONFIG_SYS_NO_FLASH, CONFIG_SYS_DCACHE_OFF, ...
and here is another one.
Now, there are three boards enabling OF_CONTROL on SPL:
- socfpga_arria5_defconfig
- socfpga_cyclone5_defconfig
- socfpga_socrates_defconfig
This commit adds CONFIG_SPL_OF_CONTROL for them and deletes
CONFIG_SPL_DISABLE_OF_CONTROL from the other boards to invert
the logic.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Represent all available RAM in either one or two banks. The first bank
describes any RAM below 4GB. The second bank describes any RAM above 4GB.
This split is driven by the following requirements:
- The NVIDIA L4T kernel requires separate entries in the DT /memory/reg
property for memory below and above the 4GB boundary. The layout of that
DT property is directly driven by the entries in the U-Boot bank array.
- On systems with RAM beyond a physical address of 4GB, the potential
existence of a carve-out at the end of RAM below 4GB can only be
represented using multiple banks, since usable RAM is not contiguous.
While making this change, add a lot more comments re: how and why RAM is
represented in banks, and implement a few more "semantic" functions that
define (and perhaps later detect at run-time) the size of any carve-out.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The return value of query_sdram_size() is assigned directly to
gd->ram_size in dram_init(). Adjust the return type to match the field
it's assigned to. This has the beneficial effect that on 64-bit systems,
the return value can correctly represent large RAM sizes over 4GB.
For similar reasons, change the type of variable size_bytes in the same
way.
query_sdram_size() would previously clip the detected RAM size to at most
just under 4GB in all cases, since on 32-bit systems, larger values could
not be represented. Disable this feature on 64-bit systems since the
representation restriction does not exist.
On 64-bit systems, never call get_ram_size() to validate the detected/
calculated RAM size. On any system with a secure OS/... carve-out, RAM
may not have a single contiguous usable area, and this can confuse
get_ram_size(). Ideally, we'd make this call conditional upon some other
flag that indicates specifically that a carve-out is actually in use. At
present, building for a 64-bit system is the best indication we have of
this fact. In fact, the call to get_ram_size() is not useful by the time
U-Boot runs on any system, since U-Boot (and potentially much other early
boot software) always runs from RAM on Tegra, so any mistakes in memory
controller register programming will already have manifested themselves
and prevented U-Boot from running to this point. In the future, we may
simply delete the call to get_ram_size() in all cases.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The logic for simple PLLs on T124 was broken by this commit:
722e000c Tegra: PLL: use per-SoC pllinfo table instead of PLL_DIVM/N/P, etc.
Correct it by reading from the same pll_misc register that it writes to and
adding an entry for the DP PLL in the pllinfo table.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
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: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom 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: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom 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: Alexandre Courbot <acourbot@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Tom Warren <twarren@nvidia.com>
Signed-off-by: Tom 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: Alexandre Courbot <acourbot@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Tom Warren <twarren@nvidia.com>
Signed-off-by: Tom 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: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom 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: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Tom 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: Tom Warren <twarren@nvidia.com>
CPU board (E2530) has a fan - turn it on via GPIO to keep
the SoC cool.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Based on Venice2, incorporates Stephen Warren's
latest P2571 pinmux table.
With Thierry Reding's 64-bit build fixes, this
will build and and boot in 64-bit on my P2571
(when used with a 32-bit AVP loader).
Signed-off-by: Tom Warren <twarren@nvidia.com>
Derived from Tegra124, modified as appropriate during T210
board bringup. Cleaned up debug statements to conserve
string space, too. This also adds misc 64-bit changes
from Thierry Reding/Stephen Warren.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
All based off of Tegra124. As a Tegra210 board is brought
up, these may change a bit to match the HW more closely,
but probably 90% of this is identical to T124.
Note that since T210 is a 64-bit build, it has no SPL
component, and hence no cpu.c for Tegra210.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Moved Tegra config options to mach-tegra/Kconfig so that both
32-bit and 64-bit builds can co-exist for Tegra SoCs.
T210 will be 64-bit only (no SPL) and will require a 32-bit
AVP/BPMP loader.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Simon's 'tegra124: Implement spl_was_boot_source()' needs
a prototype for save_boot_params_ret() to build cleanly
for 64-bit Tegra210.
Signed-off-by: Tom Warren <twarren@nvidia.com>
A subsequent patch will enable the use of the architected timer on
ARMv8. Doing so implies that udelay() will be backed by this timer
implementation, and hence the architected timer must be ready when
udelay() is first called. The first time udelay() is used is while
resetting the debug UART, which happens very early. Make sure that
arch_timer_init() is called before that.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
On 64-bit SoCs the I-cache isn't enabled in early code, so the default
cache enable functions for 64-bit ARM can be used.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Most peripherals on Tegra can do DMA only to the lower 32-bit
address space, even on 64-bit SoCs. This limitation is
typically overcome by the use of an IOMMU. Since the IOMMU is
not entirely trivial to set up and serves no other purpose
(I/O protection, ...) in U-Boot, restrict 64-bit Tegra SoCs to
the lower 32-bit address space for RAM. This ensures that the
physical addresses of buffers that are programmed into the
various DMA engines are valid and don't alias to lower addresses.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
[swarren, stripped out changes not strictly related to warnings]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
We plan to enable device tree in SPL by default. Before doing this,
explicitly disable it for all boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
Somehow this change was dropped in the various merges. I noticed when I
came to turn off the non-driver-model support for Tegra. We need to make
this change (and deal with any problems) before going further.
Change-Id: Ib9389a0d41008014eb0df0df98c27be65bc79ce6
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
With the rename the MAINTAINER file was not updated. Fix it and the
'Chrombook' typo in Kconfig.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add a hook to allows boards to add their own init to board_init().
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This is required in order to avoid instability when running from caches
after the kernel starts.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
A harmless but confusing warning is displayed when looking up the
DisplayPort PLL. Correct this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
