The Documentation/arm64/booting.txt document says that pass in x1/x2/x3
as 0 as they are reserved for future use.
Signed-off-by: Tom Rini <trini@ti.com>
The bcm_ep board configuration is used by a number of boards
including Cygnus and NSP.
Add builds for the bcm958300k and the bcm958622hr boards.
Signed-off-by: Scott Branden <sbranden@broadcom.com>
Signed-off-by: Steve Rae <srae@broadcom.com>
Base support for the Broadcom NSP SoC.
Based on iproc-common and the SoC specific reset function.
Signed-off-by: Scott Branden <sbranden@broadcom.com>
Signed-off-by: Steve Rae <srae@broadcom.com>
Base support for the Broadcom Cygnus SoC.
Based on iproc-common and the SoC specific reset function.
Signed-off-by: Scott Branden <sbranden@broadcom.com>
Signed-off-by: Steve Rae <srae@broadcom.com>
The iproc architecture code is present in several Broadcom
chip architectures, including Cygnus and NSP.
Signed-off-by: Scott Branden <sbranden@broadcom.com>
Signed-off-by: Steve Rae <srae@broadcom.com>
Add pin mux for NAND Flash Controller (NFC). NAND can be connected
using 8 or 16 data lines, this patch adds pin mux entries for all
16 data lines.
Signed-off-by: Stefan Agner <stefan@agner.ch>
The patch fixes a corner case where adding size to DRAM start resulted
in a value (1 << 32), which in turn overflew the u32 computation, which
resulted in 0 and it therefore prevented correct setup of the MMU tables.
The addition of DRAM bank start and it's size can end up right at the end
of the address space in the special case of a machine with enough memory.
To prevent this overflow, shift the start and size separately and add them
only after they were shifted.
Hopefully, we only have systems in tree which have DRAM size aligned to
1MiB boundary. If not, this patch would break such systems. On the other
hand, such system would be broken by design anyway.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Enable Ethernet clock when Broadcom StarFighter2 Ethernet block
(CONFIG_BCM_SF2_ETH) is enabled.
Signed-off-by: Jiandong Zheng <jdzheng@broadcom.com>
Signed-off-by: Steve Rae <srae@broadcom.com>
However ep9315 don't use
interrupt vectors during startup, but _startup symbol is used inside uboot to
calculate actual monitor size.
Signed-off-by: Sergey Kostanbaev <sergey.kostanbaev@gmail.com>
Cc: albert.u.boot@aribaud.net
Enable initialization fo designware ethernet controller. With this
patch, ethernet works in my configuration, provided I set ethernet
address in the environment.
Signed-off-by: Pavel Machek <pavel@denx.de>
To fix the build error when build for Altera dev kit, not
virtual target. At same time, set the build for Altera dev
kit as default instead virtual target. With that, U-Boot
is booting well and SPL still lack of few drivers.
Signed-off-by: Chin Liang See <clsee@altera.com>
Cc: Pavel Machek <pavel@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Structure defining clock manager hardware was wrong, leading to
wrong registers being accessed and hang in MMC init.
This fixes structure to match hardware.
Signed-off-by: Pavel Machek <pavel@denx.de>
When compiling u-boot with W=1 the extern inline void for
read* is likely causing the most noise. gcc / clang will
warn there is never a actual declaration for these functions.
Instead of declaring these extern make them static inline so
it is actually declared.
cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
DRA7 evm REV G and later boards uses a vtt regulator for DDR3 termination
and this is controlled by gpio7_11. Configuring gpio7_11.
The pad A22(offset 0x3b4) is used by gpio7_11 on REV G and later boards,
and left unused on previous boards, so it is safe enough to enable gpio
on all DRA7 boards.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Currently hw leveling is enabled by default on DRA7/72.
But the hardware team suggested to use sw leveling as hw leveling
is not characterized and seen some test case failures.
So enabling sw leveling on all DRA7 platforms.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
This patch reads EFUSE_BOOTROM register to see the maximum supported
clock for CORE and TETRIS PLLs and configure them accordingly.
Acked-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
This patch adds support for parallel NOR device (S29GL512S10) present on J6-EVM.
The Flash device is connected to GPMC controller on chip-select[0] and accessed
as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits) and
is CFI compatible.
As multiple devices are share GPMC pins on this board, so following board
settings are required to detect NOR device:
SW5.1 (NAND_BOOTn) = OFF (logic-1)
SW5.2 (NOR_BOOTn) = ON (logic-0) /* Active-low */
SW5.3 (eMMC_BOOTn) = OFF (logic-1)
SW5.4 (QSPI_BOOTn) = OFF (logic-1)
And also set appropriate SYSBOOT configurations:
SW3.1 (SYSBOOT[ 8])= ON (logic-1) /* selects SYS_CLK1 speed */
SW3.2 (SYSBOOT[ 9])= OFF (logic-0) /* selects SYS_CLK1 speed */
SW3.3 (SYSBOOT[10])= ON (logic-1) /* wait-pin monitoring = enabled */
SW3.4 (SYSBOOT[11])= OFF (logic-0) /* device type: Non Muxed */
SW3.5 (SYSBOOT[12])= OFF (logic-0) /* device type: Non Muxed */
SW3.6 (SYSBOOT[13])= ON (logic-1) /* device bus-width: 1(x16) */
SW3.7 (SYSBOOT[14])= OFF (logic-0) /* reserved */
SW3.8 (SYSBOOT[15])= ON (logic-1) /* reserved */
Also, following changes are required to enable NOR Flash support in
dra7xx_evm board profile:
Emails to the board maintainer
"Rishi Bhattacharya <rishi@ti.com>"
have been bouncing.
Tom suggested to remove this board.
Remove also omap1510_udc.c because this is the last board
to enable it.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Suggested-by: Tom Rini <trini@ti.com>
mx6sxsabresd board has 2 FEC ports, each one connected to a AR8031.
Add support for one FEC port initially.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
mx6sxsabresd was not in the master branch when the conversion to the new Kconfig
style happened, so convert it now so that it can build again.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
The COL field value cannot be easily calculated from the desired
column number. Instead, there are special cases for that, see the
datasheet, MMDCx_MDCTL field description, field COL . Cater for
those special cases.
Signed-off-by: Marek Vasut <marex@denx.de>
The MX6 DRAM controller can be configured to handle 4GiB of DRAM, but
only 3840 MiB of that can be really used. In case the controller is
configured to operate a 4GiB module, the imx_ddr_size() function will
correctly compute that there is 4GiB of DRAM in the system. Firstly,
the return value is 32-bit, so the function will effectively return
zero. Secondly, the MX6 cannot address the full 4GiB, but only 3840MiB
of all that. Thus, clamp the returned size to 3840MiB in such case.
Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Tim Harvey <tharvey@gateworks.com>
This allows u-boot to load different OS or Bare Metal application on
different cores of the i.MX6 SoC.
For example: running Android on cpu0 and a RT OS like QNX/FreeRTOS on cpu1.
Signed-off-by: Gabriel Huau <contact@huau-gabriel.fr>
Acked-by: Stefano Babic <sbabic@denx.de>
Do not specify own zynq specific SPL macros
because there is no need for that.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This adds board support for the Toradex Colibri T30 module.
Working functions:
- SD card boot
- eMMC environment and boot
- USB host/USB client (on the dual role port)
- Network (via ASIX USB)
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Tom Warren <twarren@nvidia.com>
In at least Tegra124, the Tegra memory controller (MC) has a register
that controls the memory size. Read this to determine the memory size
rather than requiring this to be redundantly encoded into the ODMDATA.
This way, changes to the BCT (i.e. MC configuration) automatically
updated SW's view of the memory size, without requiring manual changes
to the ODMDATA.
Future work potentially required:
* Clip the memory size to architectural limits; U-Boot probably doesn't
and won't support either LPAE or Tegra's "swiss cheese" memory layout,
at least one of which would be required for >2GB RAM.
* Subtract out any carveout required by firmware on future SoCs.
Based-on-work-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
On Tegra114 and Tegra124 platforms, certain display-related registers cannot
be accessed unless the VPR registers are programmed. For bootloader, we
probably don't care about VPR, so we disable it (which counts as programming
it, and allows those display-related registers to be accessed).
This patch is based on the commit 5f499646c83ba08079f3fdff6591f638a0ce4c0c
in Chromium OS U-Boot project.
Signed-off-by: Andrew Chew <achew@nvidia.com>
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Signed-off-by: Bryan Wu <pengw@nvidia.com>
[acourbot: ensure write went through, vpr.c style changes]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Cc: Tom Warren <TWarren@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Terje Bergstrom <tbergstrom@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
aristainetos board was merged in u-boot-imx before
Kconfig was integrated, but it is not yet
mainline.
Signed-off-by: Stefano Babic <sbabic@denx.de>
CC: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
In the case if the 'dram_para' struct does not specify the exact bus
width or chip density, just use a trial and error method to find a
usable configuration.
Because all the major bugs in the DRAM initialization sequence are
now hopefully fixed, it should be safe to re-initialize the DRAM
controller multiple times until we get it configured right. The
original Allwinner's boot0 bootloader also used a similar
autodetection trick.
The DDR3 spec contains the package pinout and addressing table for
different possible chip densities. It appears to be impossible to
distinguish between a single chip with 16 I/O data lines and a pair
of chips with 8 I/O data lines in the case if they provide the same
storage capacity. Because a single 16-bit chip has a higher density
than a pair of equivalent 8-bit chips, it has stricter refresh timings.
So in the case of doubt, we assume that 16-bit chips are used.
Additionally, only Allwinner A20 has all A0-A15 address lines and
can support densities up to 8192. The older Allwinner A10 and
Allwinner A13 can only support densities up to 4096.
We deliberately leave out DDR2, dual-rank configurations and the
special case of a 8-bit chip with density 8192. None of these
configurations seem to have been ever used in real devices. And no
new devices are likely to use these exotic configurations (because
only up to 2GB of RAM can be populated in any case).
This DRAM autodetection feature potentially allows to have a single
low performance fail-safe DDR3 initialiazation for a universal single
bootloader binary, which can be compatible with all Allwinner
A10/A13/A20 based devices (if the ifdefs are replaced with a runtime
SoC type detection).
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The write recovery time is 15ns for all JEDEC DDR3 speed bins. And
instead of hardcoding it to 10 cycles, it is possible to set tighter
timings based on accurate calculations. For example, DRAM clock
frequencies up to 533MHz need only 8 cycles for write recovery.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
All the known Allwinner A10/A13/A20 devices are using just single rank
DDR3 memory. So don't pretend that we support DDR2 or more than one
rank, because nobody could ever test these configurations for real and
they are likely broken. Support for these features can be added back
in the case if such hardware actually exists.
As part of this code cleanup, also replace division by 1024 with
division by 1000 for the refresh timing calculations. This allows
to use the original non-skewed tRFC timing table from the DRR3 spec
and make code less confusing.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The hardware DQS gate training is a bit unreliable and does not
always find the best delay settings.
So we introduce a 32-bit 'dqs_gating_delay' variable, where each
byte encodes the DQS gating delay for each byte lane. The delay
granularity is 1/4 cycle.
Also we allow to enable the active DQS gating window mode, which
works better than the passive mode in practice. The DDR3 spec
says that there is a 0.9 cycles preamble and 0.3 cycle postamble.
The DQS window has to be opened during preamble and closed during
postamble. In the passive window mode, the gating window is opened
and closed by just using the gating delay settings. And because
of the 1/4 cycle delay granularity, accurately hitting the 0.3
cycle long postamble is a bit tough. In the active window mode,
the gating window is auto-closing with the help of monitoring
the DQS line, which relaxes the gating delay accuracy requirements.
But the hardware DQS gate training is still performed in the passive
window mode. It is a more strict test, which is reducing the results
variance compared to the training with active window mode.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
It is going to be useful in more than one place.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The stale error status should be cleared for all sun4i/sun5i/sun7i
hardware and not just for sun7i. Also there are two types of DQS
gate training errors ("found no result" and "found more than one
possible result"). Both are handled now.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This configures the PLL5P clock frequency to something in the ballpark
of 1GHz and allows more choices for MBUS and G2D clock frequency
selection (using their own divisors). In particular, it enables the use
of 2/3 clock speed ratio between MBUS and DRAM.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The sun5i hardware (Allwinner A13) introduced configurable MBUS clock
speed. Allwinner A13 uses only 16-bit data bus width to connect the
external DRAM, which is halved compared to the 32-bit data bus of sun4i
(Allwinner A10), so it does not make much sense to clock a wider
internal bus at a very high speed. The Allwinner A13 manual specifies
300 MHz MBUS clock speed limit and 533 MHz DRAM clock speed limit. Newer
sun7i hardware (Allwinner A20) has a full width 32-bit external memory
interface again, but still keeps the MBUS clock speed configurable.
Clocking MBUS too low inhibits memory performance and one has to find
the optimal MBUS/DRAM clock speed ratio, which may depend on many
factors:
http://linux-sunxi.org/A10_DRAM_Controller_Performance
This patch introduces a new 'mbus_clock' parameter for the 'dram_para'
struct and uses it as a desired MBUS clock speed target. If 'mbus_clock'
is not set, 300 MHz is used by default to match the older hardcoded
settings.
PLL5P and PLL6 are both evaluated as possible clock sources. Preferring
the one, which can provide higher clock frequency that is lower or
equal to the 'mbus_clock' target. In the case of a tie, PLL5P has
higher priority.
Attempting to set the MBUS clock speed has no effect on sun4i, but does
no harm either.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The DRAM controller allows to configure impedance either by using the
calibration against an external high precision 240 ohm resistor, or
by skipping the calibration and loading pre-defined data. The DRAM
controller register guide is available here:
http://linux-sunxi.org/A10_DRAM_Controller_Register_Guide#SDR_ZQCR0
The new code supports both of the impedance configuration modes:
- If the higher bits of the 'zq' parameter in the 'dram_para' struct
are zero, then the lowest 8 bits are used as the ZPROG value, where
two divisors encoded in lower and higher 4 bits. One divisor is
used for calibrating the termination impedance, and another is used
for the output impedance.
- If bits 27:8 in the 'zq' parameters are non-zero, then they are
used as the pre-defined ZDATA value instead of performing the ZQ
calibration.
Two lowest bits in the 'odt_en' parameter enable ODT for the DQ and DQS
lines individually. Enabling ODT for both DQ and DQS means that the
'odt_en' parameter needs to be set to 3.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The old 'await_completion' function is not sufficient, because
in some cases we want to wait for bits to be cleared, and in the
other cases we want to wait for bits to be set. So split the
'await_completion' into two new 'await_bits_clear' and
'await_bits_set' functions.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
