1. 14 Mar, 2016 2 commits
    • Simon Glass's avatar
      Kconfig: Move CONFIG_FIT and related options to Kconfig · 73223f0e
      Simon Glass authored
      There are already two FIT options in Kconfig but the CONFIG options are
      still in the header files. We need to do a proper move to fix this.
      Move these options to Kconfig and tidy up board configuration:
      Unfortunately the first one is a little complicated. We need to make sure
      this option is not enabled in SPL by this change. Also this option is
      enabled automatically in the host builds by defining CONFIG_FIT in the
      image.h file. To solve this, add a new IMAGE_USE_FIT #define which can
      be used in files that are built on the host but must also build for U-Boot
      and SPL.
      Note: Masahiro's moveconfig.py script is amazing.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      [trini: Add microblaze change, various configs/ re-applies]
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
    • Simon Glass's avatar
      freescale: Remove CONFIG_DM from header files · 9e971632
      Simon Glass authored
      Kconfig options must defined in the defconfig files. Since RSA_SOFTWARE_EXP
      relies on CONFIG_DM, unless it is set in kconfig we cannot enable RSA.
      Remove the hacks which enable CONFIG_DM in header files and update the
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
  2. 27 Jan, 2016 3 commits
    • Aneesh Bansal's avatar
      secure_boot: enable chain of trust for PowerPC platforms · d0a6d7ce
      Aneesh Bansal authored
      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: default avatarAneesh Bansal <aneesh.bansal@nxp.com>
      Acked-by: default avatarRuchika Gupta <ruchika.gupta@nxp.com>
      Reviewed-by: default avatarYork Sun <york.sun@nxp.com>
    • Aneesh Bansal's avatar
      secure_boot: split the secure boot functionality in two parts · bdc22074
      Aneesh Bansal authored
      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.
      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 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:
      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.
      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: default avatarAneesh Bansal <aneesh.bansal@nxp.com>
      Acked-by: default avatarRuchika Gupta <ruchika.gupta@nxp.com>
      Reviewed-by: default avatarYork Sun <york.sun@nxp.com>
    • Aneesh Bansal's avatar
      secure_boot: include/configs: move definition of CONFIG_CMD_BLOB · 74eecd82
      Aneesh Bansal authored
      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: default avatarAneesh Bansal <aneesh.bansal@nxp.com>
      Acked-by: default avatarRuchika Gupta <ruchika.gupta@nxp.com>
      Reviewed-by: default avatarYork Sun <york.sun@nxp.com>
  3. 02 Sep, 2015 1 commit
  4. 31 Jul, 2015 2 commits
  5. 28 Jul, 2015 1 commit
  6. 21 Apr, 2015 1 commit
    • gaurav rana's avatar
      Add bootscript support to esbc_validate. · 98cb0efd
      gaurav rana authored
      1. Default environment will be used for secure boot flow
       which can't be edited or saved.
      2. Command for secure boot is predefined in the default
       environment which will run on autoboot (and autoboot is
       the only option allowed in case of secure boot) and it
       looks like this:
       #define CONFIG_SECBOOT \
       "setenv bs_hdraddr 0xe8e00000;"                 \
       "esbc_validate $bs_hdraddr;"                    \
       "source $img_addr;"                             \
      3. Boot Script can contain esbc_validate commands and bootm command.
       Uboot source command used in default secure boot command will
       run the bootscript.
      4. Command esbc_halt added to ensure either bootm executes
       after validation of images or core should just spin.
      Signed-off-by: default avatarRuchika Gupta <ruchika.gupta@freescale.com>
      Signed-off-by: default avatarGaurav Rana <gaurav.rana@freescale.com>
      Reviewed-by: default avatarYork Sun <yorksun@freescale.com>
  7. 05 Mar, 2015 1 commit
  8. 16 Jan, 2015 1 commit
  9. 05 Dec, 2014 1 commit
    • Shengzhou Liu's avatar
      powerpc/mpc85xx: Add T1024/T1023 SoC support · f6050790
      Shengzhou Liu authored
      Add support for Freescale T1024/T1023 SoC.
      The T1024 SoC includes the following function and features:
      - Two 64-bit Power architecture e5500 cores, up to 1.4GHz
      - private 256KB L2 cache each core and shared 256KB CoreNet platform cache (CPC)
      - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving support
      - Data Path Acceleration Architecture (DPAA) incorporating acceleration
      - Four MAC for 1G/2.5G/10G network interfaces (RGMII, SGMII, QSGMII, XFI)
      - High-speed peripheral interfaces
        - Three PCI Express 2.0 controllers
      - Additional peripheral interfaces
        - One SATA 2.0 controller
        - Two USB 2.0 controllers with integrated PHY
        - Enhanced secure digital host controller (SD/eSDHC/eMMC)
        - Enhanced serial peripheral interface (eSPI)
        - Four I2C controllers
        - Four 2-pin UARTs or two 4-pin UARTs
        - Integrated Flash Controller supporting NAND and NOR flash
      - Two 8-channel DMA engines
      - Multicore programmable interrupt controller (PIC)
      - LCD interface (DIU) with 12 bit dual data rate
      - QUICC Engine block supporting TDM, HDLC, and UART
      - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
      - Support for hardware virtualization and partitioning enforcement
      - QorIQ Platform's Trust Architecture 2.0
      Differences between T1024 and T1023:
        Feature         T1024  T1023
        QUICC Engine:   yes    no
        DIU:            yes    no
        Deep Sleep:     yes    no
        I2C controller: 4      3
        DDR:            64-bit 32-bit
        IFC:            32-bit 28-bit
      Signed-off-by: default avatarShengzhou Liu <Shengzhou.Liu@freescale.com>
      Reviewed-by: default avatarYork Sun <yorksun@freescale.com>
  10. 13 May, 2014 2 commits
  11. 23 Apr, 2014 5 commits
  12. 16 Oct, 2013 1 commit
  13. 24 Jul, 2013 1 commit
  14. 24 May, 2013 1 commit
  15. 03 Oct, 2011 1 commit
    • Ruchika Gupta's avatar
      powerpc/p4080: Add support for secure boot flow · 7065b7d4
      Ruchika Gupta authored
      Pre u-boot Flow:
      1. User loads the u-boot image in flash
      2. PBL/Configuration word is used to create LAW for Flash at 0xc0000000
         (Please note that ISBC expects all these addresses, images to be
          validated, entry point etc within 0 - 3.5G range)
      3. ISBC validates the u-boot image, and passes control to u-boot
         at 0xcffffffc.
      Changes in u-boot:
      1. Temporarily map CONFIG_SYS_MONITOR_BASE to the 1M
         (The CONFIG_SYS_PBI_FLASH_WINDOW is the address map for the flash
          created by PBL/configuration word within 0 - 3.5G memory range. The
          u-boot image at this address has been validated by ISBC code)
      2. Remove TLB entries for 0 - 3.5G created by ISBC code
      3. Remove the LAW entry for the CONFIG_SYS_PBI_FLASH_WINDOW created by
         PBL/configuration word after switch to AS = 1
      Signed-off-by: default avatarRuchika Gupta <ruchika.gupta@freescale.com>
      Signed-off-by: default avatarKuldip Giroh <kuldip.giroh@freescale.com>
      Acked-by: default avatarWood Scott-B07421 <B07421@freescale.com>
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
  16. 19 May, 2011 1 commit
  17. 28 Apr, 2011 1 commit
  18. 20 Jan, 2011 1 commit
  19. 14 Jan, 2011 6 commits
  20. 12 Nov, 2010 2 commits
  21. 18 Oct, 2010 1 commit
  22. 01 Aug, 2010 1 commit
  23. 13 Apr, 2010 1 commit
  24. 12 Feb, 2010 1 commit
    • Jens Scharsig's avatar
      prepare joining at91rm9200 into at91 · 98250e8e
      Jens Scharsig authored
      * prepare joining at91 and at91rm9200
       * add modified copy of soc files to cpu/arm920t/at91 to make
         possible to compile at91rm9200 boards in at91 tree instead
         of at91rm9200
       * add header files with c structure defs for AT91 MC, ST and TC
       * the new cpu files are using at91 c structure soc access
       * please read README.soc-at91 for details
      Signed-off-by: default avatarJens Scharsig <js_at_ng@scharsoft.de>
  25. 31 Oct, 2008 1 commit