Eric Lee / smarc-uboot

27 Jul, 2016

1 commit

29 Mar, 2016

2 commits

  • 2bfe48908   SECURE_BOOT: Use default bootargs ... Browse Code »

    For secure boot, currently we were using fixed bootargs for all SoCs.
    This is not needed and we can use the bootargs which are used in
    non-secure boot.

    Signed-off-by: Aneesh Bansal
    Signed-off-by: Saksham Jain
    Reviewed-by: York Sun

    Saksham Jain
     
  • 3f701cc50   armv8: fsl-lsch3: Copy Bootscript and header from NOR to DDR ... Browse Code »

    To unify steps for secure boot for xip (eg. NOR) and non-xip memories
    (eg. NAND, SD), bootscipts and its header are copied to main memory.
    Validation and execution are performed from there.

    For other ARM Platforms (ls1043 and ls1020), to avoid disruption of
    existing users, this copy step is not used for NOR boot.

    Signed-off-by: Aneesh Bansal
    Signed-off-by: Saksham Jain
    Reviewed-by: York Sun

    Saksham Jain
     

28 Jan, 2016

1 commit

  • bdc22074c   secure_boot: split the secure boot functionality in two parts ... Browse Code »

    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

    Aneesh Bansal