u-boot.git/arch/powerpc/include, branch v2016.03

powerpc/SECURE_BOOT: Add PAMU driver

2016-02-24T16:40:55+00:00

PAMU driver basic support for usage in Secure Boot.
In secure boot PAMU is not in bypass mode. Hence to use
any peripheral (SEC Job ring in our case), PAMU has to be
configured.

The patch reverts commit 7cad2e38d61e27ea59fb7944f7e647e97ef292d3.

The Header file pamu.h and few functions in driver have been derived
from Freescale Libos.

Signed-off-by: Ruchika Gupta 
Signed-off-by: Aneesh Bansal 
Reviewed-by: York Sun

Merge branch 'master' of git://git.denx.de/u-boot-fsl-qoriq

2016-01-27T20:05:36+00:00

secure_boot: enable chain of trust for PowerPC platforms

2016-01-27T16:12:56+00:00

Chain of Trust is enabled for PowerPC platforms for Secure Boot.
CONFIG_BOARD_LATE_INIT is defined.
In board_late_init(), fsl_setenv_chain_of_trust() is called which
will perform the following:
- If boot mode is non-secure, return (No Change)
- If boot mode is secure, set the following environmet variables:
   bootdelay = 0 (To disable Boot Prompt)
   bootcmd = CONFIG_CHAIN_BOOT_CMD (Validate and execute Boot script)

Signed-off-by: Aneesh Bansal 
Acked-by: Ruchika Gupta 
Reviewed-by: York Sun

secure_boot: create function to determine boot mode

2016-01-27T16:12:42+00:00

A function is created to detrmine if the boot mode is secure
or non-secure for differnt SoC's.

Signed-off-by: Aneesh Bansal 
Acked-by: Ruchika Gupta 
Reviewed-by: York Sun

secure_boot: split the secure boot functionality in two parts

2016-01-27T16:12:32+00:00

There are two phases in Secure Boot
1. ISBC: In BootROM, validate the BootLoader (U-Boot).
2. ESBC: In U-Boot, continuing the Chain of Trust by
         validating and booting LINUX.

For ESBC phase, there is no difference in SoC's based on ARM or
PowerPC cores.

But the exit conditions after ISBC phase i.e. entry conditions for
U-Boot are different for ARM and PowerPC.
PowerPC:

If Secure Boot is executed, a separate U-Boot target is required
which must be compiled with a diffrent Text Base as compared to
Non-Secure Boot. There are some LAW and TLB settings which are
required specifically for Secure Boot scenario.

ARM:
ARM based SoC's have a fixed memory map and exit conditions from
BootROM are same irrespective of boot mode (Secure or Non-Secure).

Thus the current Secure Boot functionlity has been split into
two parts:
CONFIG_CHAIN_OF_TRUST
This will have the following functionality as part of U-Boot:
1. Enable commands like esbc_validate, esbc_halt
2. Change the environment settings based on bootmode, determined
   at run time:
     - If bootmode is non-secure, no change
     - If bootmode is secure, set the following:
         - bootdelay = 0 (Don't give boot prompt)
         - bootcmd = Validate and execute the bootscript.

CONFIG_SECURE_BOOT
This is defined only for creating a different compile time target
for secure boot.

Traditionally, both these functionalities were defined under
CONFIG_SECURE_BOOT. This patch is aimed at removing the requirement
for a separate Secure Boot target for ARM based SoC's.
CONFIG_CHAIN_OF_TRUST will be defined and boot mode will be
determine at run time.

Another Security Requirement for running CHAIN_OF_TRUST is that
U-Boot environemnt must not be picked from flash/external memory.
This cannot be done based on bootmode at run time in current U-Boot
architecture. Once this dependency is resolved, no separate
SECURE_BOOT target will be required for ARM based SoC's.

Currently, the only code under CONFIG_SECURE_BOOT for ARM SoC's is
defining CONFIG_ENV_IS_NOWHERE

Signed-off-by: Aneesh Bansal 
Acked-by: Ruchika Gupta 
Reviewed-by: York Sun

secure_boot: include/configs: move definition of CONFIG_CMD_BLOB

2016-01-27T16:12:26+00:00

CONFIG_CMD_BLOB must be defined in case of Secure Boot. It was
earlier defined in all config files. The definition has been
moved to a common file which is included by all configs.

Signed-off-by: Aneesh Bansal 
Acked-by: Ruchika Gupta 
Reviewed-by: York Sun

mailaddr: Update mail address

2016-01-27T14:32:05+00:00

The old mail address will stop working soon.
Update it all the files

Signed-off-by: Ricardo Ribalda Delgado 
Reviewed-by: Bin Meng 
Reviewed-by: Tom Rini 
Signed-off-by: Michal Simek 
Reviewed-by: Michal Simek

driver/ddr/fsl: Add workaround for A009663

2016-01-25T16:24:15+00:00

Erratum A-009663 workaround requires to set DDR_INTERVAL[BSTOPRE] to 0
before setting DDR_SDRAM_CFG[MEM_EN] and set DDR_INTERVAL[BSTOPRE]
to the desired value after DDR initialization has completed.

When DDR controller is configured to operate in auto-precharge
mode(DDR_INTERVAL[BSTOPRE]=0), this workaround is not needed.

Signed-off-by: Shengzhou Liu 
Reviewed-by: York Sun

Add more SPDX-License-Identifier tags

2016-01-19T13:31:21+00:00

In a number of places we had wordings of the GPL (or LGPL in a few
cases) license text that were split in such a way that it wasn't caught
previously.  Convert all of these to the correct SPDX-License-Identifier
tag.

Signed-off-by: Tom Rini

fsl/ddr: updated ddr errata-A008378 for arm and power SoCs

2015-12-14T02:27:28+00:00

DDR errata-A008378 applies to LS1021-20-22A-R1.0, T1023-R1.0,
T1024-R1.0, T1040-42-20-22-R1.0/R1.1, it has been fixed on
LS102x Rev2.

Signed-off-by: Shengzhou Liu 
Reviewed-by: York Sun