security-integration-tree/security-ti-u-boot.git
5 years agodefconfig: ti: Add configs for OMAP5-class secure parts ti-u-boot-2015.07
Daniel Allred [Wed, 17 Feb 2016 05:21:23 +0000 (23:21 -0600)]
defconfig: ti: Add configs for OMAP5-class secure parts

Adds new defconfig files for DRA7xx and AM57xx secure devices.
These are the same as the non-secure parts, but with the addition
of the CONFIG_TI_SECURE_DEVICE option set to 'y'.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
5 years agoARM: omap5: Add config for board/cpu fdt fixups
Daniel Allred [Wed, 17 Feb 2016 05:21:22 +0000 (23:21 -0600)]
ARM: omap5: Add config for board/cpu fdt fixups

Adds CONFIG_OF_BOARD_SETUP to the config header files
for dra7xx_evm and am57xx_evm.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
5 years agoARM: omap5: add ft_board_setup for dra7xx/am57xx
Daniel Allred [Wed, 17 Feb 2016 05:21:21 +0000 (23:21 -0600)]
ARM: omap5: add ft_board_setup for dra7xx/am57xx

Adds the board specific ft_board_setup() functions that
are called when CONFIG_OF_BOARD_SETUP is defined. These functions
will currently just call the ft_cpu_setup() function.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
5 years agoARM: omap5: add hooks for cpu/SoC fdt fixups
Daniel Allred [Wed, 17 Feb 2016 05:21:20 +0000 (23:21 -0600)]
ARM: omap5: add hooks for cpu/SoC fdt fixups

Adds an fdt.c file in that defines the ft_cpu_setup() function,
which should be called from a board-specific ft_board_setup()).
This ft_cpu_setup() will currently do nothing for non-secure (GP)
devices but contains pertinent updates for booting on secure (HS)
devices.

Update the omap5 Makefile to include the fdt.c in the build.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
5 years agoARM: omap4/5: Add device type to CPU string
Daniel Allred [Wed, 17 Feb 2016 05:21:19 +0000 (23:21 -0600)]
ARM: omap4/5: Add device type to CPU string

Update the CPU string output so that the device
type is now included as part of the CPU string that
is printed as the SPL or u-boot comes up. This update
adds a suffix of the form "-GP" or "-HS" for production
devices, so that general purpose (GP) and high security
(HS) can be distiguished. Applies to all OMAP5 variants.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
5 years agospl: build: ti: add support for secure boot images
Daniel Allred [Wed, 17 Feb 2016 05:21:18 +0000 (23:21 -0600)]
spl: build: ti: add support for secure boot images

Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE
is in use (which it should be when building for secure parts),
the TI secure development package is used to create a valid
secure boot image. The u-boot SPL build processes is NOT aware
of the details of creating the boot image - all of that information
is encapsulated in the TI secure development package, which is
available from TI. More info can be found in README.ti-secure

Right now, two image types are generated, MLO and X-LOADER. The types
are important, as certain boot modes implemented by the device's ROM
boot loader require one or the other (they are not equivalent). The
output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The
u-boot-spl_HS_MLO image is also copied to a file named MLO, which is
the name that the device ROM bootloader requires for loading from the
FAT partition of an SD card (same as on non-secure devices).

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
5 years agoti_omap5_common: Update SPL start address on secure parts
Daniel Allred [Wed, 17 Feb 2016 05:21:17 +0000 (23:21 -0600)]
ti_omap5_common: Update SPL start address on secure parts

Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving
the start address past secure reserved memory and the size of the
security certificate that precedes the boot image on secure devices).
Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the
internal memory actually available on the various device flavors
(Common minimum internal RAM guaranteed for various flavors of
DRA7xx/AM57xx is 512KB).

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
5 years agodefconfig: Add configs for AM43xx secure parts
Madan Srinivas [Wed, 17 Feb 2016 05:21:16 +0000 (23:21 -0600)]
defconfig: Add configs for AM43xx secure parts

Adds new defconfig files for AM43xx secure devices.
These are the same as the non-secure parts, except for
CONFIG_TI_SECURE_DEVICE option set to 'y'
CONFIG_ISW_ENTRY_ADDR updated for secure images.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
5 years agoti: AM43xx: board: Detect AM43xx HS EVM
Srinivas, Madan [Wed, 17 Feb 2016 05:21:15 +0000 (23:21 -0600)]
ti: AM43xx: board: Detect AM43xx HS EVM

Adds code to detect AM43xx HS EVMS - the string in the
I2C EEPROM for HS EVMs differs from GP EVMs.

Modifies findfdt command to pick up am437x-gp-evm.dtb for
the HS EVMs also, as the boards are similar except for
some security specific changes around power supply and
enclosure protection.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
5 years agoti: AM43xx: Use CONFIG options from SOC Kconfig
Madan Srinivas [Wed, 17 Feb 2016 05:21:14 +0000 (23:21 -0600)]
ti: AM43xx: Use CONFIG options from SOC Kconfig

Updates configs/am43xx_evm.h to use CONFIG options from
SOC specific Kconfig file for various calculations.

On AM43x devices, the address of SPL entry point  depends on
the device type, i.e. whether it is secure or non-secure.

Further, for non-secure devices, the SPL entry point is different
between  USB HOST boot mode, other "memory" boot modes (MMC, NAND)
and "peripheral" boot modes (UART, USB)

To add to the complexity, on secure devices, in addition to the
above differences, the SPL entry point can change because of the
space occupied by other components (other than u-boot or spl)
that go into a secure boot image.

To prevent the user from having to modify source files every time
any component of the secure image changes, the value of
CONFIG_SPL_TEXT_BASE has been set using a Kconfig option that
is supplied in the am43xx_*_defconfig files

Using the CONFIG options also enables us to do away with some
compile time flags that were used to specify CONFIG_SPL_TEXT_BASE
for different boot modes.

On QSPI devices, the same problem described above occurs w.r.t. the
address of the u-boot entry point in flash, when booting secure
devices. To handle this, CONFIG_SYS_TEXT_BASE is also setup via
a Kconfig option and the defconfig files.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
5 years agoti: AM43xx: config.mk: Add support for generating secure boot images
Daniel Allred [Wed, 17 Feb 2016 05:21:13 +0000 (23:21 -0600)]
ti: AM43xx: config.mk: Add support for generating secure boot images

Modifies the config.mk to build secure images when building
the SPL for secure devices.

Depending on the boot media, different images are needed
for secure devices. The build generates u-boot*_HS_* files
as appropriate for the different boot modes. The same u-boot
binary file is processed slightly differently to produce a
different boot image, depending on whether the user wants to
boot off SPI, QSPI or other boot media.

Refer to README.ti-secure for more information.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
5 years agoti: omap-common: Add commands for generating secure SPL images
Daniel Allred [Wed, 17 Feb 2016 05:21:12 +0000 (23:21 -0600)]
ti: omap-common: Add commands for generating secure SPL images

Adds a centralized config_secure.mk in omap-common for
OMAP-style TI secure devices to use for boot image generation

Depending on the boot media, different images are needed for
secure devices. These commands generates u-boot*_HS_* files that
need to be used to boot secure devices.

Please refer to README.ti-secure for more information.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
5 years agoti: omap-common: Add Kconfig file for secure device support
Srinivas, Madan [Wed, 17 Feb 2016 05:21:11 +0000 (23:21 -0600)]
ti: omap-common: Add Kconfig file for secure device support

Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on
when building images for secure devices. This flag is used
to invoke the secure image creation tools for creating a
boot image that can be used on secure devices. This flag
may also be used to conditionally compile code specific
to secure devices.

This terminology will be used by all OMAP architecture devices,
hence introducing to a common location.

With the creation of Kconfig for omap-common, moved the
sourcing of the Kconfig files for the omap3/4/5 and am33xx
devices from arch/arm/KConfig to the omap-common one.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
5 years agoarm: Kconfig: Add support for AM43xx SoC specific Kconfig
Madan Srinivas [Wed, 17 Feb 2016 05:21:10 +0000 (23:21 -0600)]
arm: Kconfig: Add support for AM43xx SoC specific Kconfig

Adding support for AM43xx secure devices require the addition
of some SOC specific config options like the amount of memory
used by public ROM and the address of the entry point of u-boot
or SPL, as seen by the ROM code, for the image to be built
correctly.

This mandates the addition of am AM43xx CONFIG option and the
ARM Kconfig file has been modified to source this SOC Kconfig
file. Moving the TARGET_AM43XX_EVM config option to the SOC
KConfig and out of the arch/arm/Kconfig.

Updating defconfigs to add the CONFIG_AM43XX=y statement and
removing the #define CONFIG_AM43XX from the header file.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
5 years agoarm: am33xx: Kconfig: Add secure device definitions
Madan Srinivas [Wed, 17 Feb 2016 05:21:09 +0000 (23:21 -0600)]
arm: am33xx: Kconfig: Add secure device definitions

Adds a new Kconfig file for AM33xx class devices. We
need a common place to define CONFIG parameters
for these SOCs, especially for adding support
for secure devices.

a) Adds a definition for ISW_ENTRY_ADDR. This is the
address to which the ROM branches when the SOC
ROM hands off execution to the boot loader.
CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set
to this value for AM43xx devices.

b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to
calculate CONFIG_SPL_MAX_SIZE. This value indicates the
amount of memory needed by the ROM to store data during
the boot process.

Currently, these CONFIG options are used only by AM43xx,
but in future other AM33xx class SOCs will also use them.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
5 years agodoc: Add info on using secure devices from TI
Daniel Allred [Wed, 17 Feb 2016 05:21:08 +0000 (23:21 -0600)]
doc: Add info on using secure devices from TI

Adds doc/README.ti-secure file to explain in generic terms
how boot images need to be created for secure devices from
Texas Instruments.

Specific details for creating secure boot images for the
AM43xx, DRA7xx and AM57xx secure devices from Texas
Instruments are also provided in the README file.

Secure devices require a security development package (SECDEV)
package that can be downloaded from:

http://www.ti.com/mysecuresoftware

Login is required and access is granted under appropriate NDA
and export control restrictions.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
5 years agoboard: ti: am57xx: Set ethernet MAC addresses from EEPROM to env
Roger Quadros [Tue, 16 Feb 2016 15:33:38 +0000 (17:33 +0200)]
board: ti: am57xx: Set ethernet MAC addresses from EEPROM to env

The MAC addresses for the PRU Ethernet ports will be available in the
board EEPROM as an address range. Populate those MAC addresses (if valid)
into the u-boot environment so that they can be passed on to the
device tree during fdt_fixup_ethernet().

Signed-off-by: Roger Quadros <rogerq@ti.com>
5 years agoti: common: add board_ti_get_eth_mac_addr()
Roger Quadros [Tue, 16 Feb 2016 15:33:37 +0000 (17:33 +0200)]
ti: common: add board_ti_get_eth_mac_addr()

This is an accessor function to get the
Ethernet MAC addresses from the board EEPRM.

Signed-off-by: Roger Quadros <rogerq@ti.com>
5 years agonet: export eth_setenv_enetaddr_by_index()
Roger Quadros [Tue, 16 Feb 2016 15:33:36 +0000 (17:33 +0200)]
net: export eth_setenv_enetaddr_by_index()

Some TI boards (e.g. IDK) have 4 to 6 ethernet ports and
this function is handy at board.c to configure the
MAC address of the ports.

Signed-off-by: Roger Quadros <rogerq@ti.com>
5 years agoti: common: Add mac_addr in struct ti_commmon_eeprom
Roger Quadros [Tue, 16 Feb 2016 15:33:35 +0000 (17:33 +0200)]
ti: common: Add mac_addr in struct ti_commmon_eeprom

Some boards contain Ethernet MAC addresses in the EEPROM.
Provide for such boards to store it into the ti_common_eeprom
for later use.

Update ti_i2c_eeprom_am_get() to store the EEPROM MAC address
into ti_common_eeprom.

Signed-off-by: Roger Quadros <rogerq@ti.com>
5 years agoconfigs: keystone: Set mmc as default boot for k2g-evm
Yan Liu [Sat, 13 Feb 2016 18:20:57 +0000 (13:20 -0500)]
configs: keystone: Set mmc as default boot for k2g-evm

For k2l, k2e and k2hk, ubi is set to default boot in uboot
environment settings; while for k2g, mmc should be the
default boot. This patch is to set mmc as default for k2g-evm

Signed-off-by: Yan Liu <yan-liu@ti.com>
5 years agoam43xx: qspi: Fix config to select SPI mode
Vignesh R [Fri, 12 Feb 2016 06:45:03 +0000 (12:15 +0530)]
am43xx: qspi: Fix config to select SPI mode

CONFIG_SF_DEFAULT_MODE is used to select default SPI mode when using
sf commands. Therefore fix am43xx to use CONFIG_SF_DEFAULT_MODE instead
of CONFIG_DEFAULT_SPI_MODE.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
5 years agoARM: am335x: Fix build warning with usbspl_defconfig
Lokesh Vutla [Wed, 10 Feb 2016 04:41:14 +0000 (10:11 +0530)]
ARM: am335x: Fix build warning with usbspl_defconfig

The following build warning appears when using am335x_evm_usbspl_defconfig:

board/ti/am335x/board.c:555:13: warning: 'request_and_set_gpio' defined but not used [-Wunused-function]
static void request_and_set_gpio(int gpio, char *name)
              ^
board/ti/am335x/board.c:587:25: warning: 'cdce913_data' defined but not used [-Wunused-variable]
static struct clk_synth cdce913_data = {

Fixing it by guarding the clock synthesizer data appropriately.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: k2g: Add support for different arm/device speeds
Lokesh Vutla [Mon, 8 Feb 2016 12:45:45 +0000 (18:15 +0530)]
ARM: k2g: Add support for different arm/device speeds

The maximum device and arm speeds can be determined by reading
EFUSE_BOOTROM register. As there is already a framework for reading this
register, adding support for all possible speeds on k2g devices.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: ks2: Allow for board specific speed definitions
Lokesh Vutla [Mon, 8 Feb 2016 11:22:29 +0000 (16:52 +0530)]
ARM: ks2: Allow for board specific speed definitions

Its not compulsory that speed definition should be same on EFUSE_BOOTROM
register for all keystone 2 devices. So, allow for board specific
speed definitions.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoboard: ti: dra7xx: Fix MMC1_CD muxing
Kishon Vijay Abraham I [Fri, 5 Feb 2016 06:43:42 +0000 (12:13 +0530)]
board: ti: dra7xx: Fix MMC1_CD muxing

GPIO is used for MMC1 card detect. Change the MUX mode accordingly for
dra7xx platforms.

Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
5 years agoconfigs: Add AM335x ICEv2 defconfig
Lokesh Vutla [Fri, 29 Jan 2016 11:17:12 +0000 (16:47 +0530)]
configs: Add AM335x ICEv2 defconfig

Adding the minimum defconfig for AM335x ICEv2 platform.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoconfig: env: Set AM335x-ICEv2 board specific env
Lokesh Vutla [Tue, 2 Feb 2016 03:03:19 +0000 (08:33 +0530)]
config: env: Set AM335x-ICEv2 board specific env

Populate the right dtb file and console for AM335x-ICEv2 board.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoboard: AM335x-ICEv2: Add cpsw support
Lokesh Vutla [Mon, 1 Feb 2016 12:09:17 +0000 (17:39 +0530)]
board: AM335x-ICEv2: Add cpsw support

In order to enable cpsw on AM335x ICEv2 board, the following needs to be done:

1)There are few on board jumper settings which gives a choice between
cpsw and PRUSS, that needs to be properly selected[1]. Even after selecting
this, there are few GPIOs which control these muxes that needs to be held high.

2) The clock to PHY is provided by a PLL-based clock synthesizer[2] connected
via I2C. This needs to properly programmed and locked for PHY operation.
And PHY needs to be reset before before being used, which is also held by
a GPIO.

3) RMII mode needs to be selected.

[1] http://www.ti.com/lit/zip/tidr336
[2] http://www.ti.com/lit/ds/symlink/cdce913.pdf

Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: AM33xx: Add support for Clock Synthesizer
Lokesh Vutla [Thu, 4 Feb 2016 05:11:37 +0000 (10:41 +0530)]
ARM: AM33xx: Add support for Clock Synthesizer

The CDCE913 and CDCEL913 devices are modular PLL-based, low cost,
high performance , programmable clock synthesizers. They generate
upto 3 output clocks from a single input frequency. Each output can
be programmed for any clock-frequency.

Adding support for the same.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoboard: AM335x-ICEv2: Add DDR data
Lokesh Vutla [Fri, 29 Jan 2016 11:06:35 +0000 (16:36 +0530)]
board: AM335x-ICEv2: Add DDR data

AM335x ICEv2 contains a 2Gbit(128Mx16) of DDR3 SDRAM(MT41J128M16JT-125),
capable of running at 400MHz. Adding this specific DDR configuration
details running at 400MHz.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoboard: AM335x-ICEv2: Add pinmux support
Lokesh Vutla [Fri, 29 Jan 2016 10:59:55 +0000 (16:29 +0530)]
board: AM335x-ICEv2: Add pinmux support

Add necessary pinmux support for AM335x ICEv2 board.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoboard: AM335x-ICEv2: Add epprom support
Lokesh Vutla [Fri, 29 Jan 2016 09:29:06 +0000 (14:59 +0530)]
board: AM335x-ICEv2: Add epprom support

Similar to other TI's AM335x platforms, AM335x ICEv2 also has an
eeprom populated for its unique identification. Adding this info
so that AM335x ICEv2 specific initialization can be done.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM : DRA7: Switch QSPI to use MODE-0 at 64MHz
Vignesh R [Thu, 4 Feb 2016 10:41:38 +0000 (10:41 +0000)]
ARM : DRA7: Switch QSPI to use MODE-0 at 64MHz

TI QSPI controller on DRA74/DRA72 EVM can support up to 64MHz in MODE-0,
whereas MODE-3 is limited to 48MHz. Hence, switch to MODE-0 for better
throughput.
Also, add iodelay settings for the same.

Signed-off-by: Vignesh R <vigneshr@ti.com>
5 years agoboard: ti: am57xx: Handle detection of SR2.0 variations for X15/GPEVM
Nishanth Menon [Wed, 3 Feb 2016 21:50:57 +0000 (15:50 -0600)]
board: ti: am57xx: Handle detection of SR2.0 variations for X15/GPEVM

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 es2plus variations
and hope that the spins stop here.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoboard: ti: am57xx: Switch HDMI muxing on SR 2.0 for X15/GPEVM
Nishanth Menon [Wed, 3 Feb 2016 21:50:56 +0000 (15:50 -0600)]
board: ti: am57xx: Switch HDMI muxing on SR 2.0 for X15/GPEVM

HDMI_LS_OE from GPIO6_28(Y9) to GPIO2_30 (AG8) to avoid to avoid a
1.8V GPIO toggling a 3.3V input when the SD card in HS 1.8V mode. This
requires a minor change in our configuration for ES1.1 Vs ES2.0 setup.
We split the HDMI LS_OE configuration based on the ES of the silicon
and by default configure the pinmux for MMC1_SDWP as driver_off.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoARM: OMAP5/DRA7: expose do_set_iodelay
Nishanth Menon [Wed, 3 Feb 2016 21:50:55 +0000 (15:50 -0600)]
ARM: OMAP5/DRA7: expose do_set_iodelay

do_set_iodelay can now be used from board files based on needs of the
platforms variation they have.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoARM: OMAP5/DRA7: Split iodelay functionality into sub steps
Nishanth Menon [Wed, 3 Feb 2016 21:50:54 +0000 (15:50 -0600)]
ARM: OMAP5/DRA7: Split iodelay functionality into sub steps

Since many platforms may need different pad configuration required
depending on variation of the platform with minor deltas, it is
easier to maintain a sub step based approach to allow for pin mux
and iodelay configuration which may depend on the platform variations
and need to be done in IO isolation.

While we retain the older __recalibrate_iodelay function which provides
a ready sequencing, __recalibrate_iodelay_start and
__recalibrate_iodelay_end may be alternatively used now and the callers
will be responsible for the correct sequencing of operations.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoboard: ti: am57xx: Introduce iodelay timing for SR2.0 for X15/GPEVM
Nishanth Menon [Wed, 3 Feb 2016 21:50:53 +0000 (15:50 -0600)]
board: ti: am57xx: Introduce iodelay timing for SR2.0 for X15/GPEVM

BeagleBoard-X15 platform should  switch over to SR2.0 devices
in production. With this, a new set of iodelay timing is necessary
for various peripherals.

The configuration is as follows:
VIN3A: VIP_MANUAL2
RGMII0: GMAC_RGMII0_MANUAL1
RGMII1: GMAC_RGMII1_MANUAL1

Data has been generated from Pin Configuration Tool (PCT) revision
1.3.10 (Jan 2016).

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoboard: ti: am57xx: Fix MMC1_CD muxing
Nishanth Menon [Wed, 3 Feb 2016 21:50:52 +0000 (15:50 -0600)]
board: ti: am57xx: Fix MMC1_CD muxing

We use MMC1_CD as a GPIO, so mux it as such for all am57xx platforms.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoboard: ti: am57xx: Update SR1.1 RGMII0 iodelay timings for x15/GPEVM
Nishanth Menon [Wed, 3 Feb 2016 21:50:51 +0000 (15:50 -0600)]
board: ti: am57xx: Update SR1.1 RGMII0 iodelay timings for x15/GPEVM

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>
5 years agoti_armv7_common.sh: Enable CONFIG_CMD_TIME
Yan Liu [Mon, 25 Jan 2016 21:11:59 +0000 (16:11 -0500)]
ti_armv7_common.sh: Enable CONFIG_CMD_TIME

In order to measure various throughput in uboot, 'time' command
is prefered. This patch is to enables 'time' command by enabling
CONFIG_CMD_TIME in ti_armv7_common.h

Signed-off-by: Yan Liu <yan-liu@ti.com>
5 years agoboard: am57xx: Fix sysinfo string length
Lokesh Vutla [Thu, 14 Jan 2016 08:21:36 +0000 (13:51 +0530)]
board: am57xx: Fix sysinfo string length

sizeof a pointer will always return the size of the data type it is pointing
to. Board detection logic for am57xx prints the board name into sysinfo
with size as pointer size. Because of this only 3 letters are printed: "Boa".
So, pass the maximum size for printing. Also print the Revision of the board
along with it.

Fixes: ab0e3372ff2e ("board: ti: AM57xx: Add detection logic for AM57xx-evm")
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: DRA7-evm: Update memory info in banks
Lokesh Vutla [Fri, 6 Nov 2015 15:50:17 +0000 (21:20 +0530)]
ARM: DRA7-evm: Update memory info in banks

Updating the memory banks properly so that DT is populated accordingly.
And updating this only after DDR is properly detected by eeprom, so that
git bisect is still maintained.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: DRA7: EMIF: Add 4GB DDR settings
Lokesh Vutla [Wed, 2 Dec 2015 06:38:03 +0000 (12:08 +0530)]
ARM: DRA7: EMIF: Add 4GB DDR settings

The REVH and later versions of DRA7-evm uses MICRON MT41K512M16HA-125 memory
chips which is of size 4GB(2GB on EMIF1 and 2GB on EMIF2). Add support for the
same.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: DRA7: Move emif settings to board specific files
Lokesh Vutla [Tue, 1 Dec 2015 11:49:18 +0000 (17:19 +0530)]
ARM: DRA7: Move emif settings to board specific files

The newer versions of DRA7 boards has EEPROM populated with DDR
size specified in it. Moving DRA7 specific emif related settings
to board files so that emif settings can be identified based on EEPROM.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: DRA7: Enable EEPROM support
Lokesh Vutla [Thu, 3 Dec 2015 08:10:07 +0000 (13:40 +0530)]
ARM: DRA7: Enable EEPROM support

Enable EEPROM support for DRA74-evm.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoti: common: dra7: Add standard access for board description EEPROM
Lokesh Vutla [Wed, 13 Jan 2016 11:33:06 +0000 (17:03 +0530)]
ti: common: dra7: Add standard access for board description EEPROM

DRA7 EVM revH and later EVMs have EEPROM populated that can contain board
description information such as name, revision, DDR definition, etc. Adding
support for this EEPROM format.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoti: common: Generalize the eeprom driver apis
Lokesh Vutla [Thu, 21 Jan 2016 11:20:43 +0000 (16:50 +0530)]
ti: common: Generalize the eeprom driver apis

The common eeprom driver is being used by DRA7 amd AM* series, but the apis
are as board_am_*. To make things clear rename all these apis to board_ti*.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoti: common: Prepare for eeprom consolidation
Lokesh Vutla [Thu, 21 Jan 2016 09:40:06 +0000 (15:10 +0530)]
ti: common: Prepare for eeprom consolidation

TI boards follows two different formats for eeprom, one for AM series and
one for DRA7 series. In order to support both the formats in a single driver,
copying the commonly used fields into a known location of SRAM into a known
format.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoti: common: Disable direct access to eeprom contents
Lokesh Vutla [Thu, 21 Jan 2016 10:56:35 +0000 (16:26 +0530)]
ti: common: Disable direct access to eeprom contents

The common eeprom driver should not allow others to access the eeprom contents
directly. Few of the AM33xx and AM43xx configuration apis tries to directly
access the eeprom contents. So, adding the necessary apis in eeprom driver
for getting the eeprom contents.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoti: AM437x: Fix gpi2c_init call protection
Dave Gerlach [Wed, 6 Jan 2016 20:41:54 +0000 (14:41 -0600)]
ti: AM437x: Fix gpi2c_init call protection

For AM437x, gpi2c_init relies on a static local variable 'init' to
ensure the i2c initialization routines only get called once from
bdbd76b04c15 ("ti: AM437x: Add gpi2c_init before attempting to
scale MPU voltage rail"). However, this function is called very early,
before BSS is available, so we cannot rely on the value of 'init' to be
zero on first access, especially after a warm reset. Because of this it
is possible that gpi2c_init never initializes i2c at all, leading to
MPU voltage scaling not happening which can cause boot to fail.

Also, we need to initialize the variable to a non-zero value so that the
compiler does not 'optimize' and place the value in bss anyway.

In order to avoid this, let's rename the variable to 'first_time' to
completely avoid any confusion, initialize it to true and then set the
variable to false after we run once so that we don't re-initialize i2c
when the function is called again.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: am335x: env: Fix mmcboot settings
Lokesh Vutla [Fri, 18 Dec 2015 10:12:44 +0000 (15:42 +0530)]
ARM: am335x: env: Fix mmcboot settings

Remove an extra fi command in mmcboot which is not used.
Also add envboot to mmcboot so that uEnv.txt can be loaded from
both SD and emmc.

Reported-by: Craig McQueen <craig.mcqueen@innerrange.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoconfigs: k2g_evm/keyston2: Fix pmmc binary name update
Nishanth Menon [Mon, 7 Dec 2015 17:49:06 +0000 (11:49 -0600)]
configs: k2g_evm/keyston2: Fix pmmc binary name update

When we use the following in bootargs:
v1=abc
v2=123-${v1}
echo ${v2}
we get 123-${v1}
This was discussed in https://patchwork.ozlabs.org/patch/552864/
and Wolfgang disagrees that we should do recursive variable parsing.

So, fix it up to parse during run command itself. Kind of a little
convoluted, but anyways..

Fixes: c83bd9820e9a ("configs: k2g_evm/keystone2: Rename pmmc binary to be generic")
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agocommon: cli_hush: Fix up simple typo
Nishanth Menon [Fri, 4 Dec 2015 19:12:53 +0000 (13:12 -0600)]
common: cli_hush: Fix up simple typo

Correct the spelling for character..

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agok2g: add missing get_pmmc_ramfs for ramfs rootfs
Murali Karicheri [Sat, 5 Dec 2015 01:45:41 +0000 (01:45 +0000)]
k2g: add missing get_pmmc_ramfs for ramfs rootfs

Add the missing get_pmmc_ramfs in the PMCC env macro.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
5 years agokeystone2: add env script for booting with an initramfs with firmware
Murali Karicheri [Sat, 5 Dec 2015 01:45:40 +0000 (01:45 +0000)]
keystone2: add env script for booting with an initramfs with firmware

This patch updates the env script to include a initramfs with firmware
loaded and provided to kernel through second argument of bootz command
during boot. Defined DEFAULT_FW_INITRAMFS_BOOT_ENV to have all of the
required env variables and use it in evm specific config file.

The K2 linux drivers for PCIe and NetCP (1G, 10G) requires serdes
firmwares. These requires firmware to be available early through the boot
process in some cases to satisfy firmware requests from driver. Hence use
a small initramfs to provide the same and update boot env to accommodate
this in the boot flow. This method is used when rootfs is nfs and ubifs.
This fs contains just lib/firmware folder with all required firmware.

When rootfs is on initramfs, then the filesystem has the firmware under
lib/firmware and this early initramfs is not required and is not used.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
5 years agoconfigs: k2g_evm/keystone2: Rename pmmc binary to be generic
Menon, Nishanth [Thu, 3 Dec 2015 04:27:01 +0000 (04:27 +0000)]
configs: k2g_evm/keystone2: Rename pmmc binary to be generic

To stay in sync with future variations of SoC, firmware is now renamed
to ti-sci-firmware-<soc_variant>.bin. Update the configuration for the
same.

Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Russ Dill <russ.dill@ti.com>
5 years agoboard: ti: am57xx: update RGMII1 io-delay values for 2.0 silicon
Schuyler Patton [Wed, 2 Dec 2015 00:56:58 +0000 (18:56 -0600)]
board: ti: am57xx: update RGMII1 io-delay values for 2.0 silicon

The 1.3a rev of the AM572x-IDK board has 2.0 silicon on it which
requires an update to the io-delay values for cpsw ethernet port 1.
The RGMII1 IO Delay values are 2.0 estimated values. These
values will need to be verified once device characterization is
complete. Characterization of the 2.0 device will be a significant
time from now. Without this update for 2.0 silicon the RGMII1 will
not work.

These values for RGMII1 will work on 1.1 and 2.0 silicon. The
datasheet used is SPRS953P from November 2015.

Signed-off-by: Schuyler Patton <spatton@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: k2g: configs: Fix default boot cmd when env is not present
Lokesh Vutla [Wed, 25 Nov 2015 06:00:27 +0000 (11:30 +0530)]
ARM: k2g: configs: Fix default boot cmd when env is not present

run command has the capability of taking different commands as input and
run then one by one. If any input command fails then the run command exists
without running the remaining input commands.

It is expected that default boot commmand looks for envboot, if not available
then boot from preferred boot option. But both the options are arguments to
the same run command. So when envboot fails the run command exits without
booting from boot option. So separate these into two run commands.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoti_armv7_common: env: Fix prefetch abort with large buffers
Lokesh Vutla [Tue, 24 Nov 2015 11:47:50 +0000 (17:17 +0530)]
ti_armv7_common: env: Fix prefetch abort with large buffers

There are certain environment variables whose length is greater than
the defined IO buffer size. When printing these environment variables
a prefetch abort happens and resets the cpu: http://pastebin.ubuntu.com/13492109/

Enable CONFIG_SYS_VSNPRINTF which takes care of this overflow condition
and avoids resetting of CPU. With this only the CONFIG_SYS_CBSIZE length is
printed even though length is greater. So increasing the IO buffer size to
1024.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agospi: ti_qspi: Use 4-byte opcode for mmap read
Ravi Babu [Tue, 24 Nov 2015 06:32:39 +0000 (12:02 +0530)]
spi: ti_qspi: Use 4-byte opcode for mmap read

ti-qspi driver currently uses 3-byte addressing mode(and opcodes) for
memory-mapped read. This restricts maximum addressable flash size to
16MB.
Enable the 4-byte addressing(and use 4-byte opcode) for memory-mapped
read to allow access to addresses above 16MB.

Signed-off-by: Ravi Babu <ravibabu@ti.com>
[vigneshr@ti.com: Re-word commit description]
Signed-off-by: Vignesh R <vigneshr@ti.com>
5 years agoti: AM437x: Add gpi2c_init before attempting to scale MPU voltage rail
Dave Gerlach [Tue, 24 Nov 2015 15:23:40 +0000 (09:23 -0600)]
ti: AM437x: Add gpi2c_init before attempting to scale MPU voltage rail

With the new board detection logic introduced in e3ad3a2ca4ec ("ti:
AM437x: Use generic EEPROM detection logic") the board eeprom is read
once and then cached in sram. In the case of a warm reset on am437x,
the context of sram is maintained though the reset so read_eeprom is
able to fall back to this data, however because of the fallback the
internal gpi2c_init call is skipped which previously was configuring
the i2c bus before the PMIC voltage change functions were called
for the MPU voltage rail.

Because of this, PMIC functions at this early stage of boot fail during
a warm reset because the i2c bus has not been initialized. Add an
explicit call to gpi2c_init before attempting to scale the voltage rails
so that we are always able to communicate with the PMIC. This path that
fails is unique to am437x board configuration.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: keystone: K2G: power-off DSP during boot
Suman Anna [Thu, 19 Nov 2015 00:02:37 +0000 (18:02 -0600)]
ARM: keystone: K2G: power-off DSP during boot

The DSPs are powered on by default upon a Power ON reset, and
they are powered off on current Keystone 2 SoCs - K2HK, K2L, K2E
during the boot in u-boot. This is not functional on K2G though.
Extend the existing DSP power-off support to the only DSP present
on K2G. Do note that the PSC clock domain module id for DSP on K2G
differs from that of previous Keystone2 SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: keystone: Use macro for DSP GEM power domain
Suman Anna [Thu, 19 Nov 2015 00:02:36 +0000 (18:02 -0600)]
ARM: keystone: Use macro for DSP GEM power domain

Define a macro for the DSP GEM power domain id number and
use it instead of a hard-coded number in the code that
disables all the DSPs on various Keystone2 SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: keystone: remove double include of hardware.h
Suman Anna [Thu, 19 Nov 2015 00:02:35 +0000 (18:02 -0600)]
ARM: keystone: remove double include of hardware.h

The file asm/arm/hardware.h is included twice in the source
file arch/arm/mach-keystone/keystone.c. Fix this duplicate
header inclusion.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoam33xx: Remove serial_init in s_init for QSPI/NOR XIP boot
Vignesh R [Mon, 23 Nov 2015 08:40:08 +0000 (14:10 +0530)]
am33xx: Remove serial_init in s_init for QSPI/NOR XIP boot

serial_init() reads global_data, since global_data is not yet
initialized, this can cause unwanted behaviour leading to QSPI XIP boot
hang. Also, since serial_init() is anyways called later from
boar_init_f(), it does not make sense to do the same in s_init().

Tested on AM437x IDK EVM with QSPI XIP boot.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
5 years agoconfigs: ti_armv7_keystone2: Get pmmc binary from {bootdir} in UBI
Suman Anna [Fri, 20 Nov 2015 21:55:40 +0000 (15:55 -0600)]
configs: ti_armv7_keystone2: Get pmmc binary from {bootdir} in UBI

The PMMC firmware binary is currently fetched from different locations
between the MMC boot and UBI boot modes for K2G SoC. Fix up the
get_pmmc_ubi env variable so that the PMMC firmware binary location
in UBI mode matches that of MMC boot. This allows the file system
to place the PMMC binary at the same place as the kernel, DT blob
and boot monitor binaries, and make it identical for MMC and UBI
boot modes.

Fixes: 123e72bd60a9 ("ARM: keystone: K2G: Add PMMC remoteproc device")
Signed-off-by: Suman Anna <s-anna@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Acked-by: Denys Dmytriyenko <denys@ti.com>
5 years agoARM: keystone2: configs: Correct burn_uboot_sp erase size
Franklin S Cooper Jr [Wed, 18 Nov 2015 19:06:10 +0000 (13:06 -0600)]
ARM: keystone2: configs: Correct burn_uboot_sp erase size

The NOR flash on Keystone 2 evms has a u-boot-spl partition size of
0x80000.

Currently burn_uboot_spi will erase 0x100000 from the spi NOR which will
cause a partial erase of the misc partition.

Fix this by correcting the erase size.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
5 years agoboard: ti: am57xx: Fix HDMI HPD detect muxing
Steve Kipisz [Thu, 19 Nov 2015 15:20:43 +0000 (09:20 -0600)]
board: ti: am57xx: Fix HDMI HPD detect muxing

SPI1_CS2 pin is expected to be used as GPIO rather than as HDMI HPD
mode, so update the same.

Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
5 years agoti_omap5_common: AM57xx: Add selection of OSD display dtbs
Nishanth Menon [Mon, 16 Nov 2015 19:56:19 +0000 (13:56 -0600)]
ti_omap5_common: AM57xx: Add selection of OSD display dtbs

Add capability to select the right dtb based on board names. This
however, does need "auto detection" which is not possible at this
point in time.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoboard: ti: am57xx: Fix up some missing pin mux
Steve Kipisz [Thu, 12 Nov 2015 00:47:37 +0000 (18:47 -0600)]
board: ti: am57xx: Fix up some missing pin mux

There were some missing pin mux for the AM572x and AM571x IDK boards.
Fix them here

Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
5 years agoti: common: Makefile: Compile board detection only on need
Nishanth Menon [Wed, 11 Nov 2015 21:42:55 +0000 (15:42 -0600)]
ti: common: Makefile: Compile board detection only on need

We need to build board detection only on platforms that explicitly
state the need to build common headers. For other platforms, just
introduce a dummy build rule

Fixes: f2e1cb47242c ("ti: common: Add standard access for board description EEPROM")

Reported-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoARM: am43xx: Enable QUAD read support for ti_qspi
Vignesh R [Wed, 11 Nov 2015 04:41:49 +0000 (10:11 +0530)]
ARM: am43xx: Enable QUAD read support for ti_qspi

Enable QUAD read support for ti_qspi on am43xx, this
increases read performance to 4 MB/s.

Signed-off-by: Vignesh R <vigneshr@ti.com>
5 years agospi: ti_qspi: Add dummy readl for bus sync
Vignesh R [Wed, 11 Nov 2015 04:41:48 +0000 (10:11 +0530)]
spi: ti_qspi: Add dummy readl for bus sync

Add dummy readl after invalidating cmd field of QSPI_CMD_REG to ensure
bus sync. Without this device's CS is not deactivated reliably leading
to failure to enumerate flash or failure to set quad enable bit on
Macronix flash present on am437x-sk and am437x-idk evms.

Signed-off-by: Vignesh R <vigneshr@ti.com>
5 years agoHACK: ARM: DRA7: Configure DSP & IVA voltage domains for OPP_HIGH
Suman Anna [Wed, 11 Nov 2015 22:36:11 +0000 (16:36 -0600)]
HACK: ARM: DRA7: Configure DSP & IVA voltage domains for OPP_HIGH

The current bootloaders has all the Voltage domains setup and
configured for OPP_NOM. Update the voltage domain data on DSP
and IVA Voltage domains to be configured for OPP_HIGH. This is
being done to meet the performance needs of 1080p MultiMedia
usecases and other DSP usecases. This change is done for all
the existing DRA7xx/AM57xx platforms.

The OPP_HIGH voltage settings are done in u-boot and the clock
configuration 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
   SGX/DSP are unused.
3. The IVA and DSP DPLLs are not essential for u-boot
   functionality, and similar DPLL clock configuration code
   has been cleaned up in v2014.10 kernel. See commit,
   02c4153 ("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.

The GPU voltage domain is also updated to OPP_HIGH on platforms
with ganged voltage rails supplying either of the IVA or DSP
voltage domains. Following is the complete list of voltage
domains updated:
   AM57xx EVM / Beagle-x15 : IVA, DSPEVE & GPU (SMPS45)
   AM571x / AM572x IDK     : IVA, DSPEVE & GPU (SMPS45)
   DRA72x EVM              : IVA, DSPEVE & GPU (SMPS3)
   DRA74x EVM              : IVA (SMPS8) and DSPEVE (SMPS45)

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoboard: ti: am57xx: Add support for the am571x idk
Steve Kipisz [Tue, 10 Nov 2015 00:34:49 +0000 (18:34 -0600)]
board: ti: am57xx: Add support for the am571x idk

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>
5 years agoboard: ti: am57xx: Add support for am572x idk
Steve Kipisz [Tue, 10 Nov 2015 00:34:48 +0000 (18:34 -0600)]
board: ti: am57xx: Add support for am572x idk

The AM572x-IDK board (Industrial Dev Kit) is a board based on TI's AM5728x
SOC which has a dual core 1.5GHz A15 processor. This board is a development
platform for the Industrial market with:
- 2GB 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 others.

The link to the data sheet and TRM can be found here:

http://www.ti.com/product/AM5728

Signed-off-by: Schuyler Patton <spatton@ti.com>
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoboard: ti: AM57xx: Add detection logic for AM57xx-evm
Steve Kipisz [Tue, 10 Nov 2015 00:34:47 +0000 (18:34 -0600)]
board: ti: AM57xx: Add detection logic for AM57xx-evm

Current AM57xx evm supports both BeagleBoard-X15
(http://beagleboard.org/x15) and AM57xx EVM
(http://www.ti.com/tool/tmdxevm5728).

The AM572x EValuation Module(EVM) provides an affordable platform to
quickly start evaluation of Sitara. ARM Cortex-A15 AM57x Processors
(AM5728, AM5726, AM5718, AM5716) and accelerate development for HMI,
machine vision, networking, medical imaging and many other industrial
applications. This EVM is based on the same BeagleBoard-X15 Chassis
and adds mPCIe, mSATA, LCD, touchscreen, Camera, push button and TI's
wlink8 offering.

Since the EEPROM contents are compatible between the BeagleBoard-X15 and
the AM57xx-evm, we add support for the detection logic to enable
support for various user programmable scripting capability.

NOTE: U-boot configuration is currently a superset of AM57xx evm and
BeagleBoard-X15 and no additional configuration tweaking is needed.

This change also sets up the stage for future support of TI AM57xx EVMs
to the same base bootloader build.

Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoARM: OMAP4/5: Add generic board detection hook
Steve Kipisz [Tue, 10 Nov 2015 00:34:46 +0000 (18:34 -0600)]
ARM: OMAP4/5: Add generic board detection hook

Many TI EVMs have capability to store relevant board information
such as DDR description in EEPROM. Further many pad configuration
variations can occur as part of revision changes in the platform.
In-order to support these at runtime, we for a board detection hook
which is available for override from board files that may desire to do
so.

NOTE: All TI EVMs are capable of detecting board information based on
early clocks that are configured. However, in case of additional needs
this can be achieved within the override logic from within the board
file.

Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoti: AM437x: Use generic EEPROM detection logic
Nishanth Menon [Tue, 10 Nov 2015 00:34:45 +0000 (18:34 -0600)]
ti: AM437x: Use generic EEPROM detection logic

Now that we have a generic TI eeprom logic which can be reused accross
platforms, reuse the same.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Steven Kipisz <s-kipisz2@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
5 years agoti: am335x: Use generic EEPROM detection logic
Nishanth Menon [Tue, 10 Nov 2015 00:34:44 +0000 (18:34 -0600)]
ti: am335x: Use generic EEPROM detection logic

Use the generic EEPROM detection logic instead of duplicating the AM
eeprom logic.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Steven Kipisz <s-kipisz2@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
5 years agoti: common: board_detect: Add ability to setup board information
Nishanth Menon [Tue, 10 Nov 2015 00:34:43 +0000 (18:34 -0600)]
ti: common: board_detect: Add ability to setup board information

Kernel stores information to the RTC_SCRATCH0 and RTC_SCRATCH1
registers for wakeup from RTC-only mode. Parse these registers during
SPL boot and jump to the kernel resume vector if the device is waking
up from RTC-only mode

During the normal boot patch the SCRATCH1 : bits16-31 are updated
with the eeprom read board type data. In the rtc_only boot path the
rtc scratchpad register is read and the board type is determined and
correspondingly ddr dpll parameters are set. This is done so as to
avoid costly i2c read to eeprom.

So, we update the eeprom data store region with data corresponding to
this.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoti: common: Add standard access for board description EEPROM
Lokesh Vutla [Tue, 10 Nov 2015 00:34:42 +0000 (18:34 -0600)]
ti: common: Add standard access for board description EEPROM

Several TI EVMs have EEPROM that can contain board description information
such as revision, DDR definition, serial number, etc. In just about all
cases, these EEPROM are on the I2C bus and provides us the opportunity
to centralize the generic operations involved.

The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM,
AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format.
However, DRA-7* EVMs, OMAP4SDP use a modified format.

We hence introduce logic which is generic between these platforms
without enforcing any specific format. This allows the boards to use the
relevant format for operations that they might choose.

This module will compile for all TI SoC based boards when I2C is enabled,
even non-TI boards that do not have the EEPROM. If the functions are not
used, they will not be linked in.

It is important to note that this logic is fundamental to the board
configuration process such as DDR configuration which is needed in
SPL, hence cannot be part of the standard u-boot driver model (which
is available later in the process). Hence, to aid efficiency, the
eeprom contents are copied over to SRAM scratchpad memory area at the
first invocation to retrieve data.

The follow on patches introduce the use of this library for AM335x,
AM437x, and AM57xx.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoARM: OMAP3: define SRAM scratch space
Nishanth Menon [Tue, 10 Nov 2015 00:34:41 +0000 (18:34 -0600)]
ARM: OMAP3: define SRAM scratch space

based on upstream commit 60c7c30aa084 ("omap-common: Common boot code
OMAP3 support and cleanup")

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoARM: OMAP4/5: Centralize gpi2c_init
Steve Kipisz [Tue, 10 Nov 2015 00:34:40 +0000 (18:34 -0600)]
ARM: OMAP4/5: Centralize gpi2c_init

Centralize gpi2c_init into omap_common from the sys_proto header so
that the information can be reused across SoCs.

Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoARM: OMAP4/5: Centralize early clock initialization
Steve Kipisz [Tue, 10 Nov 2015 00:34:39 +0000 (18:34 -0600)]
ARM: OMAP4/5: Centralize early clock initialization

Early clock initialization is currently done in two stages for OMAP4/5
SoCs. The first stage is the initialization of console clocks and
then we initialize basic clocks for functionality necessary for SoC
initialization and basic board functionality.

By splitting up prcm_init and centralizing this clock initialization,
we setup the code for follow on patches that can do board specific
initialization such as board detection which will depend on these
basic clocks.

As part of this change, since the early clock initialization
is centralized, we no longer need to expose the console clock
initialization.

NOTE: we change the sequence slightly by initializing console clocks
timer after the io settings are complete, but this is not expected
to have any functioanlity impact since we setup the basic IO drive
strength initialization as part of do_io_settings.

Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoboard: ti: beagle_x15: Rename to indicate support for TI am57xx evms
Steve Kipisz [Tue, 10 Nov 2015 00:34:38 +0000 (18:34 -0600)]
board: ti: beagle_x15: Rename to indicate support for TI am57xx evms

BeagleBoard X15 (http://beagleboard.org/x15) support in u-boot does
actually support two different platform configuration offered by
TI. In addition to BeagleBoard X15, it also supports the TMDXEVM5728
(or more commonly known as AM5728-evm).

Information about the TI AM57xx EVM can be found here
http://www.ti.com/tool/tmdxevm5728

The EVM configuration is 1-1 compatible with BeagleBoard X15 with the
additional support for mPCIe, mSATA, LCD, touchscreen, Camera, push
button and TI's wlink8 offering.

Hence, we rename the beagle_x15 directory to am57xx to support TI
EVMs that use the AM57xx processor. By doing this we have common code
reuse. This sets the stage to have a common u-boot image solution for
multiple TI EVMs such as that already done for am335x and am437x. This
sets the stage for upcoming multiple TI EVMs that share the same code
base.

NOTE: Commit eae7ae185335 ("am437x: Add am57xx_evm_defconfig using
CONFIG_DM") introduced DT support for beagle_x15 under am57xx_evm
platform name. However, this ignored the potential confusion arising for
users as a result. To prevent this, existing beagle_x15_defconfig is
renamed as am57xx_evm_nodt_defconfig to denote that this is the "non
device tree" configuration for the same platform. We still retain
am57xx-beagle-x15.dts at this point, since we just require the common
minimum dts.

As a result of this change, users should expect changes in build
procedures('make am57xx_evm_nodt_defconfig' instead of 'make
beagle_x15_defconfig'). Hopefully, this would be a one-time change.

Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Schuyler Patton <spatton@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoMakefile: Include vendor common library in include search path
Nishanth Menon [Tue, 10 Nov 2015 00:34:37 +0000 (18:34 -0600)]
Makefile: Include vendor common library in include search path

When the vendor common libraries exists, then board should be able to
reference headers located there, rather than having to do weird logic
such as '#include "../common/xyz.h"'.

Signed-off-by: Nishanth Menon <nm@ti.com>
5 years agoARM: DRA72-evm: mux: Add virtual and manual mode settings
Lokesh Vutla [Wed, 28 Oct 2015 06:05:58 +0000 (11:35 +0530)]
ARM: DRA72-evm: mux: Add virtual and manual mode settings

Inorder to meet the timing characterstics needed for the each interface,
either VIRTUAL or MANUAL mode needs to be enabled. Enabling these VIRTUAL
and MANUAL modes for the required pins on DRA72-evm.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: AM57x: Update EMIF registers
Lokesh Vutla [Tue, 13 Oct 2015 09:59:45 +0000 (15:29 +0530)]
ARM: AM57x: Update EMIF registers

There are certain EMIF timing failures seen on the some x15 boards. Updating
the EMIF settings to get rid of these timing failures.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agonet: Increase the size of the net_boot_file_name buffer
Jacob Stiffler [Wed, 30 Sep 2015 14:12:05 +0000 (10:12 -0400)]
net: Increase the size of the net_boot_file_name buffer

commit 11a69ff85b0a459f4ac096ae054d0b527d44b095 upstream.

The net_boot_file_name buffer is used as storage for the bootfilename
command line argument to network boot commands such as tftp and nfs.

Increase the size of this buffer to 1024 bytes as the current size of
128 bytes is restrictive for arbitrary paths on the server.

Signed-off-by: Jacob Stiffler <j-stiffler@ti.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: dra7xx_evm: Add DFU support for qspi flash
Vignesh R [Wed, 28 Oct 2015 04:53:31 +0000 (10:23 +0530)]
ARM: dra7xx_evm: Add DFU support for qspi flash

This adds support to update firmware on qspi flash using DFU.

On device:
=> setenv dfu_alt_info ${dfu_alt_info_qspi}
=> dfu 0 sf 0:0

On host:
$ sudo dfu-util -l
$ sudo dfu-util -D MLO -a MLO
$ sudo dfu-util -D u-boot.img -a u-boot.img

Signed-off-by: Vignesh R <vigneshr@ti.com>
5 years agoam43xx_evm: Add DFU support for qspi flash
Vignesh R [Wed, 28 Oct 2015 04:53:30 +0000 (10:23 +0530)]
am43xx_evm: Add DFU support for qspi flash

This adds support to update firmware on qspi flash present on
am437x-sk-evm and am43xx-epos-evm via DFU.

On device:
=> setenv dfu_alt_info ${dfu_alt_info_qspi}
=> dfu 0 sf 0:0

On host:
$ sudo dfu-util -l
$ sudo dfu-util -D u-boot.bin -a u-boot.bin

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
5 years agodfu: dfu_sf: Pass duplicate devstr to parse_dev
Vignesh R [Wed, 28 Oct 2015 04:53:29 +0000 (10:23 +0530)]
dfu: dfu_sf: Pass duplicate devstr to parse_dev

parse_dev() alters the string pointed by devstr parameter. Due to this
subsequent parsing of sf entities will fail, as string pointed by devstr
is no longer valid sf dev arguments.
Fix this by passing pointer to the copy of the string to parse_dev
instead of pointer to the actual devstr.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
5 years agodfu: dfu_sf: Take the start address into account
Fabio Estevam [Wed, 28 Oct 2015 04:53:28 +0000 (10:23 +0530)]
dfu: dfu_sf: Take the start address into account

commit 2727f3bfba1bc78ca517984c2c9e0c473aeedbf4 upstream.

The dfu_alt_info_spl variable allows passing a starting point
for the binary to be flashed in the SPI NOR.

For example, if we have 'dfu_alt_info_spl=spl raw 0x400', this means
that we want to flash the binary starting at address 0x400.

In order to do so we need to erase the entire sector and write to
the the subsequent SPI NOR sectors taking such start address
into account for the address calculations.

Tested by succesfully writing SPL binary into 0x400 offset and
the u-boot.img at offset 64 kiB of a SPL NOR.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
[trini: Use lldiv for the math]
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
5 years agodfu: dfu_sf: Use the erase sector size for erase operations
Fabio Estevam [Wed, 28 Oct 2015 04:53:27 +0000 (10:23 +0530)]
dfu: dfu_sf: Use the erase sector size for erase operations

commit f4c92582137a645ffc42346d7176ddd1462c2be0 upstream.

SPI NOR flashes need to erase the entire sector size and we cannot pass
any arbitrary length for the erase operation.

To illustrate the problem:

Copying data from PC to DFU device
Download    [=========================] 100%       478208 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
state(10) = dfuERROR, status(14) = Something went wrong, but the
device does not know what it was
Done!

In this case, the binary has 478208 bytes and the M25P32 SPI NOR
has an erase sector of 64kB.

478208  = 7 entire sectors of 64kiB + 19456 bytes.

Erasing the first seven 64 kB sectors works fine, but when trying
to erase the remainding 19456 causes problem and the board hangs.

Fix the issue by always erasing with the erase sector size.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
5 years agoARM: k2g: configs: Add support to save env in MMC
Lokesh Vutla [Tue, 27 Oct 2015 08:57:16 +0000 (14:27 +0530)]
ARM: k2g: configs: Add support to save env in MMC

Adding support to save env in MMC on k2g platforms, as it is the
preferred peripheral in saving env.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: DRA7: emif: Check for enable bits before updating leveling output
Lokesh Vutla [Mon, 19 Oct 2015 09:58:58 +0000 (15:28 +0530)]
ARM: DRA7: emif: Check for enable bits before updating leveling output

Read and write leveling can be enabled independently. Check for these
enable bits before updating the read and write leveling output values.
This will allow to use the combination of software and hardware leveling.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoARM: DRA7: configs: Prepare for detecting memory > 2GB
Lokesh Vutla [Thu, 22 Oct 2015 10:17:51 +0000 (15:47 +0530)]
ARM: DRA7: configs: Prepare for detecting memory > 2GB

Enable configs that are required for detecting memory > 2GB.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>