1. 17 Mar, 2015 6 commits
  2. 15 Mar, 2015 1 commit
  3. 05 Mar, 2015 2 commits
    • gaurav rana's avatar
      SECURE BOOT: Add command for validation of images · 47151e4b
      gaurav rana authored
      1. esbc_validate command is meant for validating header and
         signature of images (Boot Script and ESBC uboot client).
         SHA-256 and RSA operations are performed using SEC block in HW.
         This command works on both PBL based and Non PBL based Freescale
         platforms.
         Command usage:
         esbc_validate img_hdr_addr [pub_key_hash]
      2. ESBC uboot client can be linux. Additionally, rootfs and device
         tree blob can also be signed.
      3. In the event of header or signature failure in validation,
         ITS and ITF bits determine further course of action.
      4. In case of soft failure, appropriate error is dumped on console.
      5. In case of hard failure, SoC is issued RESET REQUEST after
         dumping error on the console.
      6. KEY REVOCATION Feature:
         QorIQ platforms like B4/T4 have support of srk key table and key
         revocation in ISBC code in Silicon.
         The srk key table allows the user to have a key table with multiple
         keys and revoke any key in case of particular key gets compromised.
         In case the ISBC code uses the key revocation and srk key table to
         verify the u-boot code, the subsequent chain of trust should also
         use the same.
      6. ISBC KEY EXTENSION Feature:
         This feature allows large number of keys to be used for esbc validation
         of images. A set of public keys is being signed and validated by ISBC
         which can be further used for esbc validation of images.
      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>
      47151e4b
    • Rob Herring's avatar
      gpt: support random UUIDs without setting environment variables · 0c7e8d13
      Rob Herring authored
      Currently, an environment variable must be used to store the randomly
      generated UUID for each partition. This is not necessary, so make storing
      the UUID optional. Now passing uuid_disk and uuid are optional when random
      UUIDs are enabled.
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Acked-by: default avatarPrzemyslaw Marczak <p.marczak@samsung.com>
      0c7e8d13
  4. 04 Mar, 2015 1 commit
    • Shaveta Leekha's avatar
      powerpc/mpc85xx: Add DSP side awareness for Freescale Heterogeneous SoCs · b8bf0adc
      Shaveta Leekha authored
      The code provides framework for heterogeneous multicore chips based on StarCore
      and Power Architecture which are chasis-2 compliant, like B4860 and B4420
      
      It will make u-boot recognize all non-ppc cores and peripherals like
      SC3900/DSP CPUs, MAPLE, CPRI and print their configuration in u-boot logs.
      Example boot logs of B4860QDS:
      
      U-Boot 2015.01-00232-geef6e36-dirty (Jan 19 2015 - 11:58:45)
      
      CPU0:  B4860E, Version: 2.2, (0x86880022)
      Core:  e6500, Version: 2.0, (0x80400120)
      Clock Configuration:
             CPU0:1600 MHz, CPU1:1600 MHz, CPU2:1600 MHz, CPU3:1600 MHz,
             DSP CPU0:1200 MHz, DSP CPU1:1200 MHz, DSP CPU2:1200 MHz, DSP CPU3:1200 MHz,
             DSP CPU4:1200 MHz, DSP CPU5:1200 MHz,
             CCB:666.667 MHz,
             DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), IFC:166.667 MHz
             CPRI:600  MHz
             MAPLE:600  MHz, MAPLE-ULB:800  MHz, MAPLE-eTVPE:1000 MHz
             FMAN1: 666.667 MHz
             QMAN:  333.333 MHz
      
      Top level changes include:
      (1) Top level CONFIG to identify HETEROGENUOUS clusters
      (2) CONFIGS for SC3900/DSP components
      (3) Global structures like "cpu_type" and "MPC85xx_SYS_INFO"
          updated for dsp cores and other components
      (3) APIs to get DSP num cores and their Mask like:
              cpu_dsp_mask, cpu_num_dspcores etc same as that of PowerPC
      (5) Code to fetch and print SC cores and other heterogenous
          device's frequencies
      (6) README added for the same
      Signed-off-by: default avatarShaveta Leekha <shaveta@freescale.com>
      Reviewed-by: default avatarYork Sun <yorksun@freescale.com>
      b8bf0adc
  5. 02 Mar, 2015 2 commits
    • Tom Rini's avatar
      MAINTAINERS, git-mailrc: Update my email address · 4e34d610
      Tom Rini authored
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      4e34d610
    • Raul Cardenas's avatar
      imx6: Added DEK blob generator command · 0200020b
      Raul Cardenas authored
      Freescale's SEC block has built-in Data Encryption
      Key(DEK) Blob Protocol which provides a method for
      protecting a DEK for non-secure memory storage.
      SEC block protects data in a data structure called
      a Secret Key Blob, which provides both confidentiality
      and integrity protection.
      Every time the blob encapsulation is executed,
      a AES-256 key is randomly generated to encrypt the DEK.
      This key is encrypted with the OTP Secret key
      from SoC. The resulting blob consists of the encrypted
      AES-256 key, the encrypted DEK, and a 16-bit MAC.
      
      During decapsulation, the reverse process is performed
      to get back the original DEK. A caveat to the blob
      decapsulation process,  is that the DEK is decrypted
      in secure-memory and can only be read by FSL SEC HW.
      The DEK is used to decrypt data during encrypted boot.
      
      Commands added
      --------------
        dek_blob - encapsulating DEK as a cryptgraphic blob
      
      Commands Syntax
      ---------------
        dek_blob src dst len
      
          Encapsulate and create blob of a len-bits DEK at
          address src and store the result at address dst.
      Signed-off-by: default avatarRaul Cardenas <Ulises.Cardenas@freescale.com>
      Signed-off-by: default avatarNitin Garg <nitin.garg@freescale.com>
      Signed-off-by: default avatarUlises Cardenas <ulises.cardenas@freescale.com>
      Signed-off-by: default avatarUlises Cardenas-B45798 <Ulises.Cardenas@freescale.com>
      0200020b
  6. 28 Feb, 2015 1 commit
  7. 25 Feb, 2015 1 commit
  8. 24 Feb, 2015 8 commits
    • Masahiro Yamada's avatar
      ARM: davinci: remove hawkboard support · cb957cda
      Masahiro Yamada authored
      This is still a non-generic board.
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Acked-by: default avatarSughosh Ganu <urwithsughosh@gmail.com>
      Cc: Syed Mohammed Khasim <sm.khasim@gmail.com>
      Acked-by: default avatarMarek Vasut <marex@denx.de>
      cb957cda
    • Masahiro Yamada's avatar
      ARM: remove tnetv107x board support · 50b82c4b
      Masahiro Yamada authored
      This is still a non-generic board.
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Chan-Taek Park <c-park@ti.com>
      Acked-by: default avatarMarek Vasut <marex@denx.de>
      50b82c4b
    • Masahiro Yamada's avatar
      ARM: remove a320evb board support · 29fc6f24
      Masahiro Yamada authored
      This is still a non-generic board.
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Po-Yu Chuang <ratbert@faraday-tech.com>
      Acked-by: default avatarMarek Vasut <marex@denx.de>
      29fc6f24
    • Masahiro Yamada's avatar
      ARM: remove cm4008 and cm41xx board support · a2f39e83
      Masahiro Yamada authored
      These are still non-generic boards.
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Greg Ungerer <greg.ungerer@opengear.com>
      Acked-by: default avatarMarek Vasut <marex@denx.de>
      a2f39e83
    • Masahiro Yamada's avatar
      ARM: remove dkb board support · 346cfba4
      Masahiro Yamada authored
      This is still a non-generic board.
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Lei Wen <leiwen@marvell.com>
      Acked-by: default avatarMarek Vasut <marex@denx.de>
      346cfba4
    • Masahiro Yamada's avatar
      ARM: remove jadecpu board support · 41fbbbbc
      Masahiro Yamada authored
      This is still a non-generic board.
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Matthias Weisser <weisserm@arcor.de>
      Acked-by: default avatarMarek Vasut <marex@denx.de>
      41fbbbbc
    • Masahiro Yamada's avatar
      kconfig: switch to single .config configuration · e02ee254
      Masahiro Yamada authored
      When Kconfig for U-boot was examined, one of the biggest issues was
      how to support multiple images (Normal, SPL, TPL).  There were
      actually two options, "single .config" and "multiple .config".
      After some discussions and thought experiments, I chose the latter,
      i.e. to create ".config", "spl/.config", "tpl/.config" for Normal,
      SPL, TPL, respectively.
      
      It is true that the "multiple .config" strategy provided us the
      maximum flexibility and helped to avoid duplicating CONFIGs among
      Normal, SPL, TPL, but I have noticed some fatal problems:
      
      [1] It is impossible to share CONFIG options across the images.
        If you change the configuration of Main image, you often have to
        adjust some SPL configurations correspondingly.  Currently, we
        cannot handle the dependencies between them.  It means one of the
        biggest advantages of Kconfig is lost.
      
      [2] It is too painful to change both ".config" and "spl/.config".
        Sunxi guys started to work around this problem by creating a new
        configuration target.  Commit cbdd9a97 (sunxi: kconfig: Add
        %_felconfig rule to enable FEL build of sunxi platforms.) added
        "make *_felconfig" to enable CONFIG_SPL_FEL on both images.
        Changing the configuration of multiple images in one command is a
        generic demand.  The current implementation cannot propose any
        good solution about this.
      
      [3] Kconfig files are getting ugly and difficult to understand.
        Commit b724bd7d (dm: Kconfig: Move CONFIG_SYS_MALLOC_F_LEN to
        Kconfig) has sprinkled "if !SPL_BUILD" over the Kconfig files.
      
      [4] The build system got more complicated than it should be.
        To adjust Linux-originated Kconfig to U-Boot, the helper script
        "scripts/multiconfig.sh" was introduced.  Writing a complicated
        text processor is a shell script sometimes caused problems.
      
      Now I believe the "single .config" will serve us better.  With it,
      all the problems above would go away.  Instead, we will have to add
      some CONFIG_SPL_* (and CONFIG_TPL_*) options such as CONFIG_SPL_DM,
      but we will not have much.  Anyway, this is what we do now in
      scripts/Makefile.spl.
      
      I admit my mistake with my apology and this commit switches to the
      single .config configuration.
      
      It is not so difficult to do that:
      
       - Remove unnecessary processings from scripts/multiconfig.sh
        This file will remain for a while to support the current defconfig
        format.  It will be removed after more cleanups are done.
      
       - Adjust some makefiles and Kconfigs
      
       - Add some entries to include/config_uncmd_spl.h and the new file
         scripts/Makefile.uncmd_spl.  Some CONFIG options that are not
         supported on SPL must be disabled because one .config is shared
         between SPL and U-Boot proper going forward.  I know this is not
         a beautiful solution and I think we can do better, but let's see
         how much we will have to describe them.
      
       - update doc/README.kconfig
      
      More cleaning up patches will follow this.
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      e02ee254
    • Bhupesh Sharma's avatar
      fsl-ch3/lowlevel: TZPC and TZASC programming to configure non-secure accesses · 9c66ce66
      Bhupesh Sharma authored
      This patch ensures that the TZPC (BP147) and TZASC-400 programming
      happens for LS2085A SoC only when the desired config flags are
      enabled and ensures that the TZPC programming is done to allow Non-secure
      (NS) + secure (S) transactions only for DCGF registers.
      
      The TZASC component is not present on LS2085A-Rev1, so the TZASC-400
      config flag is turned OFF for now.
      Signed-off-by: default avatarBhupesh Sharma <bhupesh.sharma@freescale.com>
      Reviewed-by: default avatarYork Sun <yorksun@freescale.com>
      9c66ce66
  9. 23 Feb, 2015 1 commit
  10. 19 Feb, 2015 1 commit
  11. 13 Feb, 2015 1 commit
  12. 12 Feb, 2015 1 commit
  13. 06 Feb, 2015 5 commits
  14. 30 Jan, 2015 9 commits