Update erratum workaround for A006379 to set register CPCHDBCR0
with value 0x001e0000, replacing the old value 0x003c0000.

Signed-off-by: York Sun <york.sun@nxp.com>
Reported-by: Dave Liu <dave.liu@nxp.com>

Add support for reading bootscript and bootscript header from SD. Also
renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and
NOR flash.

Reviewed-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>

For mpc85xx SoCs, the core begins execution from address 0xFFFFFFFC.
In non-secure boot scenario from NAND, this address will map to CPC
configured as SRAM. But in case of secure boot, this default address
always maps to IBR (Internal Boot ROM).
The IBR code requires that the bootloader(U-boot) must lie in 0 to 3.5G
address space i.e. 0x0 - 0xDFFFFFFF.

For secure boot target from NAND, the text base for SPL is kept same as
non-secure boot target i.e. 0xFFFx_xxxx but the SPL U-boot binary will
be copied to CPC configured as SRAM with address in 0-3.5G(0xBFFC_0000)
As a the virtual and physical address of CPC would be different. The
virtual address 0xFFFx_xxxx needs to be mapped to physical address
0xBFFx_xxxx.

Create a new PBI file to configure CPC as SRAM with address 0xBFFC0000
and update DCFG SCRTACH1 register with location of Header required for
secure boot.

The changes are similar to
commit 467a40dfe35f48d830f01a72617207d03ca85b4d
    powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041

While P3041 has a 1MB CPC and does not require SPL. On T104x, CPC
is only 256K and thus SPL framework is used.
The changes are only applicable for SPL U-Boot running out of CPC SRAM
and not the next level U-Boot loaded on DDR.

Reviewed-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

As part of Chain of Trust for Secure boot, the SPL U-Boot will validate
the next level U-boot image. Add a new function spl_validate_uboot to
perform the validation.

Enable hardware crypto operations in SPL using SEC block.
In case of Secure Boot, PAMU is not bypassed. For allowing SEC block
access to CPC configured as SRAM, configure PAMU.

Reviewed-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>

    Fix a number of typos, including:

     * "compatble" -> "compatible"
     * "eanbeld" -> "enabled"
     * "envrionment" -> "environment"
     * "FTD" -> "FDT" (for "flattened device tree")
     * "ommitted" -> "omitted"
     * "overriden" -> "overridden"
     * "partiton" -> "partition"
     * "propogate" -> "propagate"
     * "resourse" -> "resource"
     * "rest in piece" -> "rest in peace"
     * "suport" -> "support"
     * "varible" -> "variable"

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

Define a platform data structure for the MPC85XX GPIO driver to allow
use of the driver without device tree. Users should define the GPIO
blocks for their platform like this:
  struct mpc85xx_gpio_plat gpio_blocks[] = {
         {
                 .addr = 0x130000,
                 .ngpios = 32,
         },
         {
                 .addr = 0x131000,
                 .ngpios = 32,
         },
  };

  U_BOOT_DEVICES(my_platform_gpios) = {
         { "gpio_mpc85xx", &gpio_blocks[0] },
         { "gpio_mpc85xx", &gpio_blocks[1] },
  };

This is intended to build upon the recent submission of the base
MPC85XX driver from Mario Six. We need to use that new driver
without dts support and this patch gives us that flexibility.
This has been tested on a Freescale T2080 CPU, although only the first
GPIO block.

Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Reviewed-by: Mario Six <mario.six@gdsys.cc>
Tested-by: Mario Six <mario.six@gdsys.cc>
Acked-by: Simon Glass <sjg@chromium.org>

This patch adds a driver for the built-in GPIO controller of the MPC85XX
SoC (probably supporting other PowerQUICC III SoCs as well).

Each GPIO bank is identified by its own entry in the device tree, i.e.

gpio-controller@fc00 {
      #gpio-cells = <2>;
      compatible = "fsl,pq3-gpio";
      reg = <0xfc00 0x100>
}

By default, each bank is assumed to have 32 GPIOs, but the ngpios
setting is honored, so the number of GPIOs for each bank in configurable
to match the actual GPIO count of the SoC (e.g. the 32/32/23 banks of
the P1022 SoC).

The usual functions of GPIO drivers (setting input/output mode and output
value setting) are supported.

The driver has been tested on MPC85XX, but it is likely that other
PowerQUICC III devices will work as well.

Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>

Since generic board init is enabled, this is not used. Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Some SOCs, specifically the ones in the C29x familiy can have
multiple security engines. This patch adds a system configuration
define which indicates the maximum number of SEC engines that
can be found on a SoC.

Signed-off-by: Alex Porosanu <alexandru.porosanu@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>