Use generic board setup functions by defining
CONFIG_SYS_GENERIC_BOARD.
Signed-off-by: NDmitry Lifshitz <lifshitz@compulab.co.il>

Boot from eMMC boot partition corresponds to BOOT_DEVICE_MMC2
omap_bootmode, while BOOT_DEVICE_MMC2_2 corresponds to the user
data partition boot.

Fix mmc_get_env_part() boot mode check to use a correct value.
Signed-off-by: NDmitry Lifshitz <lifshitz@compulab.co.il>

Fix cl_eeprom_read_mac_addr() return value check.
Fix long line codding style issue in board_init().
Signed-off-by: NDmitry Lifshitz <lifshitz@compulab.co.il>

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: NSricharan R <r.sricharan@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Cc: Raphael Assenat <raph@8d.com>
Cc: Stefano Babic <sbabic@denx.de>
Signed-off-by: NJeroen Hofstee <jeroen@myspectrum.nl>

This patch reads EFUSE_BOOTROM register to see the maximum supported
clock for CORE and TETRIS PLLs and configure them accordingly.
Acked-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NVitaly Andrianov <vitalya@ti.com>
Signed-off-by: NIvan 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:

This patch adds support for x16 NAND device (MT29F2G16AAD) connected to GPMC
chip-select[0] on DRA7xx EVM.
As GPMC pins are shared by multiple devices, so in addition to this patch
following board settings are required for NAND device detection [1]:

  SW5.9 (GPMC_WPN)   = OFF (logic-1)
  SW5.1 (NAND_BOOTn) = ON  (logic-0) /* Active-low */
  SW5.2 (NOR_BOOTn)  = OFF (logic-1)
  SW5.3 (eMMC_BOOTn) = OFF (logic-1)
  SW5.4 (QSPI_BOOTn) = OFF (logic-1)

And also set appropriate SYSBOOT configurations
  SW2.1 (SYSBOOT[0]) = ON  (logic-1) /* selects NAND Boot */
  SW2.2 (SYSBOOT[1]) = OFF (logic-0) /* selects NAND Boot */
  SW2.3 (SYSBOOT[2]) = OFF (logic-0) /* selects NAND Boot */
  SW2.4 (SYSBOOT[3]) = OFF (logic-0) /* selects NAND Boot */
  SW2.5 (SYSBOOT[4]) = ON  (logic-1) /* selects NAND Boot */
  SW2.6 (SYSBOOT[5]) = ON  (logic-1) /* selects NAND Boot */
  SW2.7 (SYSBOOT[6]) = OFF (logic-0) /* reserved */
  SW2.8 (SYSBOOT[7]) = OFF (logic-0) /* reserved */

  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: Addr/Data Muxed */
  SW3.5 (SYSBOOT[12])= ON  (logic-1) /* device type: Addr/Data 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 */

Following changes are required in board.cfg to enable NAND on J6-EVM:

This patch adds support for NAND device connected to GPMC chip-select on
following AM43xx EVM boards.

am437x-gp-evm: On this board, NAND Flash signals are muxed with eMMC, thus at a
  time either eMMC or NAND can be enabled. Selection between eMMC and NAND is
  controlled by:
  (a) Statically using Jumper on connecter (J89) present on board.
  (a) If Jumper on J89 is NOT used, then selection can be dynamically controlled
      by driving SPI2_CS0[MUX_MODE=GPIO] pin via software:
      SPI2_CS0 == 0: NAND (default)
      SPI2_CS0 == 1: eMMC

am43x-epos-evm: On this board, NAND Flash control lines are muxed with QSPI,
  Thus only one of the two can be used at a time. Selection is controlled by:
  (a) Dynamically driving following GPIO pin from software
      GPMC_A0(GPIO) == 0 NAND is selected (default)

NAND device (MT29F4G08AB) on these boards has:
 - data-width=8bits
 - blocksize=256KB
 - pagesize=4KB
 - oobsize=224 bytes
For above NAND device, ROM code expects the boot-loader to be flashed in BCH16
ECC scheme for NAND boot, So by default BCH16 ECC is enabled for AM43xx EVMs.
Signed-off-by: NPekon Gupta <pekon@ti.com>

This patch adds support of NOR cape[1] for both Beaglebone (white) and
Beaglebone(Black) boards. NOR Flash on this cape is connected to GPMC
chip-select[0] and accesses as external memory-mapped device.
This cape has 128Mbits(16MBytes), x16, CFI compatible NOR Flash device.

As GPMC chip-select[0] can be shared by multiple capes so NOR profile is
not enabled by default in boards.cfg. Following changes are required to
enable NOR cape detection when building am335x_boneblack board profile.
Signed-off-by: NTom Rini <trini@ti.com>

Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]

* How to boot from NAND using Memory Expander + NAND Cape ? *
 - Important: As BOOTSEL values are sampled only at POR, so after changing any
   setting on SW2 (DIP switch), disconnect and reconnect all board power supply
   (including mini-USB console port) to POR the beaglebone.

 - Selection of ECC scheme
  for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
  for NAND cape(b), ROM code expects BCH16_HW ecc-scheme

 - Selction of boot modes can be controlled via  DIP switch(SW2) present on
   Memory Expander cape.
   SW2[SWITCH_BOOT] == OFF  follow default boot order  MMC-> SPI -> UART -> USB
   SW2[SWITCH_BOOT] == ON   boot mode selected via DIP switch(SW2)
   So to flash NAND, first boot via MMC or other sources and then switch to
   SW2[SWITCH_BOOT]=ON to boot from NAND Cape.

 - For NAND boot following switch settings need to be followed
   SW2[ 1] = OFF  (SYSBOOT[ 0]==1: NAND boot mode selected )
   SW2[ 2] = OFF  (SYSBOOT[ 1]==1:       -- do --          )
   SW2[ 3] = ON   (SYSBOOT[ 2]==0:       -- do --          )
   SW2[ 4] = ON   (SYSBOOT[ 3]==0:       -- do --          )
   SW2[ 5] = OFF  (SYSBOOT[ 4]==1:       -- do --          )
   SW2[ 6] = OFF  (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
   SW2[ 7] = ON   (SYSBOOT[ 9]==0: ECC done by ROM  )
   SW2[ 8] = ON   (SYSBOOT[10]==0: Non Muxed device )
   SW2[ 9] = ON   (SYSBOOT[11]==0:    -- do --      )

[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2] http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module

*IMPORTANT NOTE*
As Beaglebone board shares the same config as AM335x EVM, so following
changes are required in addition to this patch for Beaglebone NAND cape.
(1) Enable NAND in am335x_beaglebone board profile
(2) Add CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config because:
 -  AM335x EVM has NAND device with datawidth=8, whereas
 -  Beaglebone NAND cape has NAND device with data-width=16

This patch
- consolidate CONFIG_SYS_NAND_xx and CONFIG_SPL_NAND_xx from various
  configuration files into single file.
- update MTD Partition table to match AM335x_EVM DT in linux-kernel
- segregate CONFIGs based on different boot modes (like SPL and U-Boot)
Signed-off-by: NPekon Gupta <pekon@ti.com>

When we're using EMMC_BOOT that means we have environment on eMMC so
we can make use of CONFIG_SPL_ENV_SUPPORT within Falcon Mode.
Signed-off-by: NTom Rini <trini@ti.com>

CONFIG_SPL_NET_SUPPORT is not the only time we want SPL to ahve
environment, CONFIG_SPL_ENV_SUPPORT is when we want it.
Signed-off-by: NTom Rini <trini@ti.com>

In the case of SPL on these boards we only need environment for
SPL_USBETH, so it's safe to normally use ENV_IS_NOWHERE and SPL+NAND
does not support environment today.

Cc: Hannes Petermaier <oe5hpm@oevsv.at>
Signed-off-by: NTom Rini <trini@ti.com>

There are times where we may need more than a few kilobytes of stack
space.  We also will not be using CONFIG_SPL_STACK location prior to DDR
being initialized (CONFIG_SYS_INIT_SP_ADDR is still used there) so pick
a good location within DDR for this to be.  Tested on
OMAP4/AM335x/OMAP5/DRA7xx.
Signed-off-by: NTom Rini <trini@ti.com>

On am335x_evm we only support USBETH for a networking SPL option so move
the rest of the defines under that area as that's the only time we need
(and want) environment support here.
Signed-off-by: NTom Rini <trini@ti.com>

Signed-off-by: NTom Rini <trini@ti.com>

Messages to afleming@freescale.com now bounce, and should be
directed to my personal address at afleming@gmail.com
Signed-off-by: NAndy Fleming <afleming@gmail.com>

The _config part is gone for sure, the _defconfig target could at least
work. I have not verified this for all targets though.

It's easier to Cc Masahiro on Kconfig-related changes with a git-mailrc
alias.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>

Reflect the latest build system to doc/README.SPL.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>

This document is too old and useless.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>

if status register do never set MXC_CSPICTRL_TC, spi_xchg_single
endless loops. Add a timeout here to prevent endless hang.
Signed-off-by: NHeiko Schocher <hs@denx.de>
Cc: Dirk Behme <dirk.behme@gmail.com>
Reviewed-by: NJagannadha Sutradharudu Teki <jaganna@xilinx.com>

This parameter should also be supported.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Tested-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Reviewed-by: NJagannadha Sutradharudu Teki <jaganna@xilinx.com>

The SPI transaction delay is supposed to be measured from the end of one
transaction to the start of the next. The code does not work that way, so
fix it.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Tested-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Reviewed-by: NJagannadha Sutradharudu Teki <jaganna@xilinx.com>

An incorrect message version is passed to the EC in some cases and the
parameters of one function are switched.

Fix these problems.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Tested-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Reviewed-by: NJagannadha Sutradharudu Teki <jaganna@xilinx.com>

It's usually a common pattern to free() the memory that we allocated.
Implement this here to stop leaking memory.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: NJagannadha Sutradharudu Teki <jaganna@xilinx.com>

Add support for re-relocation malloc() in arm's start-up code.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present arm defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that
the global_data pointer is set up in board_init_f(). However it is
actually set up before this, it just isn't zeroed.

If we zero the global data before calling board_init_f() then we
don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.

Make this change (on arm32 only) to simplify the init process. I
don't have the ability to test aarch64 yet.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NTom Rini <trini@ti.com>

This patch configures the qrio to trigger a core reset on
a CPU reset request.
Signed-off-by: NRainer Boschung <rainer.boschung@keymile.com>
Signed-off-by: NValentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>

To acheive this, the qrio_uprstreq() function that sets the UPRSTREQN
flag in the qrio RESCNF reg is added.
Signed-off-by: NRainer Boschung <rainer.boschung@keymile.com>
Signed-off-by: NValentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>

Check the core timer status register (TSR) for watchdog reset,
and and set the QRIO's reset reason flag REASON1[0] accordingly.

This allows the appliction SW to identify the cpu watchdog as a
reset reason, by setting the REASON1[0] flag in the QRIO.
Signed-off-by: NRainer Boschung <rainer.boschung@keymile.com>
Signed-off-by: NValentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>

To achieve this, the qrio_cpuwd_flag() function that sets the CPU watchdog
flag in the REASON1 reg is added.
Signed-off-by: NRainer Boschung <rainer.boschung@keymile.com>
Signed-off-by: NValentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>

The booting of the board is now protected by the CPU watchdog.
A failure during the boot phase will end up in board reset.
Signed-off-by: NRainer Boschung <rainer.boschung@keymile.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>

When CONFIG_WATCHDOG is defined the board initialization just performs
a WATCHDOG_RESET, an initialization of the watchdog is not done.
This has been modified fot the MPC85xx, the board initialization calls
its watchdog initialitzation allowing for full watchdog configuration
very early in the boot phase.
Signed-off-by: NRainer Boschung <rainer.boschung@keymile.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>