Apparently the indentation is wrong here, fix this to avoid compiler
warnings and puzzled readers.
Pointed out by GCC 6.2's -Wmisleading-indentation warning.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Obviously the mask for the rx and tx select field cannot be right,
as it would overlap in one and exceed the 32-bit register in the other
case. From looking at the neighbouring bits it looks like the mask
should be really 4 bits wide instead of 8.
Pointed out by a GCC 6.2 (default) warning.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
The rtl8169_intr_mask variable isn't used anywhere in the code, so
just remove it to avoid a GCC 6.2 compiler warning.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Apparently the indentation is off here, for the IGB model just want to
bail out early.
Fix this to avoid both compiler warnings and puzzled readers.
Pointed out by GCC 6.2's -Wmisleading-indentation warning.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
The indentation is misleading here and suggests that the write command
will be only executed in the else clause.
It seems like this is not intended, so fix the indentation to avoid
both compiler warnings and puzzled readers.
Pointed out by GCC 6.2's -Wmisleading-indentation warning.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This is not used by any boards. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Müller <d.mueller@elsoft.ch>
Reviewed-by: Jagan Teki <jagan@openedev.com>
This board has not been converted to DM_SERIAL by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Müller <d.mueller@elsoft.ch>
Reviewed-by: Jagan Teki <jagan@openedev.com>
This board has not been converted to DM_SERIAL by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Müller <d.mueller@elsoft.ch>
There are certain environment variables whose length is greater than
the defined IO buffer size. So, increase the IO buffer size to print the
entire variables.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The AM571x Industrial Development Kit (IDK) is a board based on TI's
AM571x SoC which has a single core 1.5GHz Cortex-A15processor. This
board is a development platform for the Industrial Market with:
- 1GB of DDR3L
- Dual 1Gbps Ethernet
- HDMI
- PRU-ICSS
- uSD
- 16GB eMMC
- CAN
- RS-485
- PCIe
- USB3.0
- Video Input Port
- Industrial IO port and expansion connector
The PRU/ICSS will be supported by 3rd party software for EtherCat,
Profibus, and other Industrial protocols.
The link to the data sheet and TRM can be found here:
http://www.ti.com/product/AM5718
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update the board pinmux for AM572x-IDK board using latest PMT[1] and the
board files named am572x_idk_v1p3b_sr2p0 that were autogenerated on
20th October, 2016 by "Steve Kipisz <s-kipisz2@ti.com>" and
"Tom Johnson <thjohnson@ti.com>".
[1] https://dev.ti.com/pinmux/app.html#/default/
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update the board pinmux for AM572x-IDK board using latest PMT[1] and the
board files named am572x_gp_evm_A3a_sr2p0 that were autogenerated on
19th October, 2016 by "Ahmad Rashed<a-rashed@ti.com>".
[1] https://dev.ti.com/pinmux/app.html#/default/
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update the timing for RGMII0 interface based on
PCT_DRA75x_DRA74x_SR1.1_v1.3.10 version (Jan 2016). This update
is for SR1.1
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
BeagleBoard-X15 Rev B1 with SR1.1 platform have incompatible changes for HDMI
GPIO requiring new dtb support. This implies we have to properly identify
the platform now as well. Hence provide a different board name for the
Rev B1 variants.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
AM57xx evm Rev A3 with SR2.0 platform have incompatible changes for HDMI
GPIO requiring new dtb support. This implies we have to properly identify
the platform now as well. Hence provide a different board name for the
Rev A3 variations.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add DT support for dra71-evm and built it as part of FIT image.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Palmas driver assumes it is always TPS659xx regulator on all DRA7xx based
boards to enable mmc regulator. This is not true always like in case of
DRA71x-evm. So get this information based on the board.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Delete omap4_vmmc_pbias_config from omap_hsmmc.c]
Signed-off-by: Tom Rini <trini@konsulko.com>
Add the pmic_data for LP873x PMIC which is used to power
up dra71x-evm.
Note: As per the DM[1] DRA71x supports only OP_NOM. So, updating
the efuse registers only to use OPP_NOM irrespective of any
CONFIG_DRA7_<VOLT>_OPP_{NOM,od,high} is defined.
[1] http://www.ti.com/product/DRA718/technicaldocuments
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Rev C version of EVM does require IODelay to be configured for RGMII
pins in MANUAL_1 configuration. Update the same based on PG2.0 initial
simulation values.
Data based on PCT_DRA72x_SR2.0_SR1.0_v1.3.0.7
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add mux and iodelay settings for dra71x-evm.
Data generated using PCT_DRA71x_SR2.0_v1.0.0.0 version (June 2016).
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The dra71x-evm is a board based on TI's DRA718 processor targeting BOM-optimized
entry infotainment systems such as display audio and is a software compatible
derivative of the highly successful DRA74 and DRA72 processor families.
More information can be found here[1].
Add epprom detection for dra71-evm.
[1] http://www.ti.com/product/dra718
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This patch adds support to update the device-tree blob to adjust the
DSP and IVA DPLL clocks pertinent to the selected OPP choice, with
the default being OPP_NOM. The voltage settings are done in u-boot,
but the actual clock configuration itself is done in kernel because
of the following reasons:
1. SoC definition constraints us to NOT to do dynamic voltage
scaling ever after the initial avs0 setting in bootloader
- so the voltage must be set in bootloader.
2. The voltage level must be set even if the IP blocks like
GPU/DSP are unused.
3. The IVA, GPU and DSP DPLLs are not essential for u-boot functionality,
and similar DPLL clock configuration code has been cleaned up in
v2014.10 u-boot release. See commit, 02c41535b6 ("ARM: OMAP4/5:
Remove dead code against CONFIG_SYS_CLOCKS_ENABLE_ALL").
The non-essential DPLLs are configured within the kernel during
the clock init step when parsing the device tree and creating
the clock devices. This approach meets both the u-boot and kernel
needs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Redefine the macros used to define the voltage values and the
efuse register offsets based on OPP for all the voltage domains.
This is done using Kconfig macros that can be set in a defconfig
or selected during a config step. This allows a voltage domain
to be configured/set to a corresponding voltage value depending
on the OPP selection choice.
The Kconfig choices have been added for MPU, DSPEVE, IVA and GPU
voltage domains, with the MPU domain restricted to OPP_NOM. The
OPP_OD and OPP_HIGH options will be added when the support for
configuring the MPU clock frequency is added. The clock
configuration for other voltage domains is out of scope in
u-boot code.
The CORE voltage domain does not have separate voltage values
and efuse register offset at different OPPs, while the MPU
voltage domain only has different efuse register offsets for
different OPPs, but uses the same voltage value. Any different
choices of OPPs for voltage domains on common ganged-rails
is automatically taken care to select the corresponding
highest OPP voltage value.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
It can be expected that different paper spins of a SoC can have
different definitions for OPP and can have their own constraints
on the boot up OPP for each voltage rail. In order to have this
flexibility, add support for dynamically selecting the OPP voltage
based on the board to handle any such exceptions.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Currently, CMD_PXE is forcibly enabled in config_distro_defaults.h, so
that general purpose distributions can rely on it being defined. This
header is included, under conditions or not, by various archs or
famillies of archs / SoCs.
However, it is very possible that boards based on those SoCs will not
have a physical ethernet connector at all, even if the have a MAC; for
example, the Nanopi Neo AIR (sunxi H3) does not. It is also possible
that network booting is absolutely not necessary for a device.
However, it is not possible to disable the PXE command, as it is
forcibly enabled and is non-configurable.
But it turns out we already have a config option to build a distro-ready
image, in the name of DISTRO_DEFAULTS.
Move CMD_PXE out of the hard-coded config_distro_defaults.h into a
Kconfig option, that gets selected by DISTRO_DEFAULTS when it is set.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Joe Hershberger <joe.hershberger@ni.com>
[trini: Make it select MENU, run moveconfig.py]
Signed-off-by: Tom Rini <trini@konsulko.com>
A number of platforms had been using the distro default feature before
it was moved to Kconfig but did not enable the new Kconfig option when
it was enabled. This caused a regression in terms of features and this
introduces breakage when more things move to Kconfig.
Signed-off-by: Tom Rini <trini@konsulko.com>
Populate the corresponding TEE image processing call to be
performed during FIT loadable processing.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Populate the corresponding TEE image processing call to be
performed during FIT loadable processing.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add an OPTEE node to the FDT when TEE installation has completed
successfully. This informs the kernel of the presence of OPTEE.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
secure_tee_install is used to install and initialize a secure TEE OS such as
Linaro OP-TEE into the secure world. This function takes in the address
where the signed TEE image is loaded as an argument. The signed TEE image
consists of a header (struct tee_header), TEE code+data followed by the
signature generated using image signing tool from TI security development
package (SECDEV). Refer to README.ti-secure for more information.
This function uses 2 new secure APIs.
1. PPA_SERV_HAL_TEE_LOAD_MASTER - Must be called on CPU Core 0. Protected
memory for TEE must be reserved before calling this function. This API
needs arguments filled into struct ppa_tee_load_info. The TEE image is
authenticated and if there are no errors, the control passes to the TEE
entry point.
2. PPA_SERV_HAL_TEE_LOAD_SLAVE - Called on other CPU cores only after
a TEE_LOAD_MASTER call. Takes no arguments. Checks if TEE was
successfully loaded (on core 0) and transfers control to the same TEE
entry point.
The code at TEE entry point is expected perform OS initialization steps
and return back to non-secure world (U-Boot).
Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
On DRA7xx platform, CPU Core 1 is not used in u-boot. However, in some
cases it is need to make secure API calls from Core 1. This patch adds
an assembly function to make a secure (SMC) call from CPU Core #1.
Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add a new image type representing Trusted Execution Environment (TEE)
image types. For example, an OP-TEE OS binary image.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
To help automate the loading of custom image types we add the ability
to define custom handlers for the loadable section types. When we find
a compatible type while loading a "loadable" image from a FIT image we
run its associated handlers to perform any additional steps needed for
loading this image.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Andre Przywara
Simon Glass
Niko Mauno
Walt Feasel
Lokesh Vutla
Schuyler Patton
Steve Kipisz
Nishanth Menon
Keerthy
Suman Anna
Tom Rini
Yann E. MORIN
Andrew F. Davis
Harinarayan Bhatta