24 Oct, 2018

1 commit

  • Found the imx8mq Rev A chip (B0 and B1 chips are ok) boot hang at CAAM RNG init.
    The jobring 0 can't complete instantiation descriptor and spins on checking ORSFR_JR0.

    In current implementation, the descriptor and jobring input and output base address locate
    on TCM, because the driver uses raw_data array in jr_data_st structure as the buffer.
    This seems cause the issue. If switched from TCM to OCRAM, the issue will go.

    Since accessing TCM by CAAM is not very reliable. Add this patch to use OCRAM for SPL case.
    The early malloc is ready on SPL before calling board_init_f. So we can use malloc to allocate
    memory instead of the raw_data array.

    Signed-off-by: Ye Li
    Reviewed-by: Peng Fan

    Ye Li
     

14 Sep, 2018

1 commit

  • The TRNG as used in RNG4, used in CAAM has a documentation issue. The
    effect is that it is possible that the entropy used to instantiate the
    DRBG may be old entropy, rather than newly generated entropy. There is
    proper programming guidance, but it is not in the documentation.

    Signed-off-by: Aymen Sghaier

    Aymen Sghaier
     

22 Aug, 2018

1 commit

  • Blob buffer size is 48 bytes larger than the plain text buffer,
    set correct range when flush the dcache. Also use cache aligned
    buffer for the blob/plain_text to avoid failure in CAAM.

    Change-Id: I3b377cfeb8f5bd9c76233827b2c9c7bd0d788c9b
    Signed-off-by: Ji Luo

    Ji Luo
     

07 Aug, 2018

1 commit

  • The imx_sec_init is called at board_f phase, this phase forbids to
    write any global variable in BSS section, because the BSS section is
    overlay with u-boot dynamic relocation entries (or DTB) which are used during
    u-boot relocation after board_f phase.

    Now the g_jrdata is in BSS section and it is initialized during imx_sec_init.
    Therefore, it destroys the relocation entries (or DTB) and causes various u-boot
    issues.

    Fix the problem by assiging default value to g_jrdata.status, so g_jrdata is
    moved to data section.

    Signed-off-by: Ye Li

    Ye Li
     

19 Jul, 2018

1 commit


17 Jul, 2018

1 commit


13 Jun, 2018

1 commit


23 May, 2018

5 commits


27 Apr, 2018

1 commit

  • This code was originally developed by Raul Cardenas
    and modified to be applied in U-Boot imx_v2017.03.

    More information about the initial submission can be seen
    in the link below:
    https://lists.denx.de/pipermail/u-boot/2016-February/245273.html

    i.MX7D has an a protection feature for Manufacturing process.
    This feature uses asymmetric encryption to sign and verify
    authenticated software handled between parties. This command
    enables the use of such feature.

    The private key is unique and generated once per device.
    And it is stored in secure memory and only accessible by CAAM.
    Therefore, the public key generation and signature functions
    are the only functions available for the user.

    The manufacturing-protection authentication process can be used to
    authenticate the chip to the OEM's server.

    Command usage:

    Print the public key for the device.
    - mfgprot pubk

    Generates Signature over given data.
    - mfgprot sign

    Signed-off-by: Raul Ulises Cardenas
    Signed-off-by: Breno Lima
    Reviewed-by: Fabio Estevam
    Reviewed-by: Ye Li
    (cherry picked from commit db2dbf622d3c711b2fbd85e6814992e023479dad)

    Breno Lima
     

05 Mar, 2018

1 commit

  • Thomas reported U-Boot failed to build host tools if libfdt-devel
    package is installed because tools include libfdt headers from
    /usr/include/ instead of using internal ones.

    This commit moves the header code:
    include/libfdt.h -> include/linux/libfdt.h
    include/libfdt_env.h -> include/linux/libfdt_env.h

    and replaces include directives:
    #include -> #include
    #include -> #include

    Reported-by: Thomas Petazzoni
    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

10 Feb, 2018

1 commit

  • Extend the instantiate_rng() function and the corresponding CAAM job
    descriptor to instantiate all RNG state handles. This moves the RNG
    instantiation code in line with the CAAM kernel driver.

    Previously, only the first state handle was instantiated. The second
    one was instantiated by the CAAM kernel driver. This works if the
    kernel runs in secure mode, but fails in non-secure mode since the
    kernel driver uses DEC0 directly instead of over the job ring
    interface. Instantiating all RNG state handles in u-boot removes the
    need for using DEC0 in the kernel driver, making it possible to use
    the CAAM in non-secure mode.

    Signed-off-by: Lukas Auer
    Tested-by: Bryan O'Donoghue
    Reviewed-by: York Sun

    Lukas Auer
     

04 Feb, 2018

1 commit

  • After enabling TrustZone various parts of the CAAM silicon become
    inaccessible to non TrustZone contexts. The job-ring registers are designed
    to allow non TrustZone contexts like Linux to still submit jobs to CAAM
    even after TrustZone has been enabled.

    The default job-ring permissions after the BootROM look like this for
    job-ring zero.

    ms=0x00008001 ls=0x00008001

    The MS field is JRaMIDR_MS (job ring MID most significant).

    Referring to "Security Reference Manual for i.MX 7Dual and 7Solo
    Applications Processors, Rev. 0, 03/2017" section 8.10.4 we see that
    JROWN_NS controls whether or not a job-ring is accessible from non
    TrustZone.

    Bit 15 (TrustZone) is the logical inverse of bit 3 hence the above value of
    0x8001 shows that JROWN_NS=0 and TrustZone=1.

    Clearly then as soon as TrustZone becomes active the job-ring registers are
    no longer accessible from Linux, which is not what we want.

    This patch explicitly sets all job-ring registers to JROWN_NS=1 (non
    TrustZone) by default and to the Non-Secure MID 001. Both settings are
    required to successfully assign a job-ring to non-secure mode. If a piece
    of TrustZone firmware requires ownership of job-ring registers it can unset
    the JROWN_NS bit itself.

    This patch in conjunction with a modification of the Linux kernel to skip
    HWRNG initialisation makes CAAM usable to Linux with TrustZone enabled.

    Signed-off-by: Bryan O'Donoghue
    Cc: Fabio Estevam
    Cc: Peng Fan
    Cc: Alex Porosanu
    Cc: Ruchika Gupta
    Cc: Aneesh Bansal
    Link: https://github.com/OP-TEE/optee_os/issues/1408
    Link: https://tinyurl.com/yam5gv9a
    Tested-by: Lukas Auer

    Bryan O'Donoghue
     

24 Jan, 2018

1 commit

  • The hash command function were not flushing the dcache before passing data
    to CAAM/DMA and not invalidating the dcache when getting data back.

    Due the data cache incoherency, HW accelerated hash commands used to fail
    with CAAM errors like "Invalid KEY Command".

    Check if pbuf and pout buffers are properly aligned to the cache line size
    and flush/invalidate the memory regions to address this issue.

    This solution is based in a previous work from Clemens Gruber in
    commit 598e9dccc75d ("crypto/fsl: fix BLOB encapsulation and
    decapsulation")

    Reported-by: Anatolij Gustschin
    Signed-off-by: Breno Lima
    Reviewed-by: York Sun

    Breno Lima
     

08 Jan, 2018

1 commit

  • The blob_encap and blob_decap functions were not flushing the dcache
    before passing data to CAAM/DMA and not invalidating the dcache when
    getting data back.
    Therefore, blob encapsulation and decapsulation failed with errors like
    the following due to data cache incoherency:
    "40000006: DECO: desc idx 0: Invalid KEY command"

    To ensure coherency, we require the key_mod, src and dst buffers to be
    aligned to the cache line size and flush/invalidate the memory regions.
    The same requirements apply to the job descriptor.

    Tested on an i.MX6Q board.

    Reviewed-by: Sumit Garg
    Signed-off-by: Clemens Gruber

    Clemens Gruber
     

04 Sep, 2017

1 commit

  • When enabling CONFIG_CMD_BLOB and/or CONFIG_CMD_DEKBLOB, the build fails
    with a linker error:
    ...
    LD u-boot
    arch/arm/mach-imx/built-in.o: In function `blob_encap_dek':
    /home/clemens/dev/u-boot/arch/arm/mach-imx/cmd_dek.c:46: undefined
    reference to `blob_dek'

    This is due to an error in the Makefile, resulting in obj-yy/obj-yn/..
    and fsl_blob.o is therefore not linked.

    Fix it by splitting it up into two obj-y lines.

    Signed-off-by: Clemens Gruber
    Reviewed-by: Fabio Estevam

    Clemens Gruber
     

23 May, 2017

1 commit


22 May, 2017

1 commit

  • Commit 94e3c8c4fd7b ("crypto/fsl - Add progressive hashing support
    using hardware acceleration.") created entries for CONFIG_SHA1,
    CONFIG_SHA256, CONFIG_SHA_HW_ACCEL, and CONFIG_SHA_PROG_HW_ACCEL.
    However, no defconfig has migrated to it. Complete the move by first
    adding additional logic to various Kconfig files to select this when
    required and then use the moveconfig tool. In many cases we can select
    these because they are required to implement other drivers. We also
    correct how we include the various hashing algorithms in SPL.

    This commit was generated as follows (after Kconfig additions):

    [1] tools/moveconfig.py -y SHA1 SHA256 SHA_HW_ACCEL
    [2] tools/moveconfig.py -y SHA_PROG_HW_ACCEL

    Note:
    We cannot move SHA_HW_ACCEL and SHA_PROG_HW_ACCEL simultaneously
    because there is dependency between them.

    Cc: Poonam Aggrwal
    Cc: Naveen Burmi
    Cc: Po Liu
    Cc: Shengzhou Liu
    Cc: Priyanka Jain
    Cc: Shaohui Xie
    Cc: Chunhe Lan
    Cc: Chander Kashyap
    Cc: Steve Rae
    Cc: Dirk Eibach
    Cc: Feng Li
    Cc: Alison Wang
    Cc: Sumit Garg
    Cc: Mingkai Hu
    Cc: York Sun
    Cc: Prabhakar Kushwaha
    Cc: Jaehoon Chung
    Cc: Akshay Saraswat
    Cc: Heiko Schocher
    Cc: Jagan Teki
    Signed-off-by: Tom Rini
    Reviewed-by: Simon Glass
    Signed-off-by: Tom Rini

    Tom Rini
     

18 Apr, 2017

4 commits


05 Jan, 2017

2 commits


24 Nov, 2016

1 commit


07 Oct, 2016

1 commit


24 Sep, 2016

2 commits


03 Aug, 2016

1 commit


27 Jul, 2016

1 commit


22 Jul, 2016

1 commit

  • 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
    Signed-off-by: Aneesh Bansal
    Signed-off-by: Sumit Garg
    Reviewed-by: Simon Glass
    Reviewed-by: York Sun

    Sumit Garg
     

16 Jul, 2016

1 commit

  • 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

    Robert P. J. Day
     

13 Jun, 2016

1 commit

  • This allows a board to configure verified boot within the SPL using
    a FIT or FIT with external data. It also allows the SPL to perform
    signature verification without needing relocation.

    The board configuration will need to add the following feature defines:
    CONFIG_SPL_CRYPTO_SUPPORT
    CONFIG_SPL_HASH_SUPPORT
    CONFIG_SPL_SHA256

    In this example, SHA256 is the only selected hashing algorithm.

    And the following booleans:
    CONFIG_SPL=y
    CONFIG_SPL_DM=y
    CONFIG_SPL_LOAD_FIT=y
    CONFIG_SPL_FIT=y
    CONFIG_SPL_OF_CONTROL=y
    CONFIG_SPL_OF_LIBFDT=y
    CONFIG_SPL_FIT_SIGNATURE=y

    Signed-off-by: Teddy Reed
    Acked-by: Simon Glass
    Acked-by: Andreas Dannenberg
    Acked-by: Sumit Garg

    Teddy Reed
     

18 May, 2016

1 commit


07 Apr, 2016

1 commit

  • LS2080A is the primary SoC, and LS2085A is a personality with AIOP
    and DPAA DDR. The RDB and QDS boards support both personality. By
    detecting the SVR at runtime, a single image per board can support
    both SoCs. It gives users flexibility to swtich SoC without the need
    to reprogram the board.

    Signed-off-by: York Sun
    CC: Prabhakar Kushwaha
    Reviewed-by: Prabhakar Kushwaha

    York Sun
     

29 Mar, 2016

2 commits

  • This commit solves CAAM coherency issue on ls2080. When caches are
    enabled and CAAM's DMA's AXI transcations are not made cacheable,
    Core reads/writes data from/to caches and CAAM does from main memory.
    This forces data flushes to synchronize various data structures. But
    even if any data in proximity of these structures is read by core,
    these structures again are fetched in caches.

    To avoid this problem, either all the data that CAAM accesses can be
    made cache line aligned or CAAM transcations can be made cacheable.

    So, this commit makes CAAM transcations as write back with write and
    read allocate.

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

    Saksham Jain
     
  • When MMU is disabled, 64-bit write must be aligned at 64-bit
    boundary. Becaue the memory location is not guaranteed to be 64-bit
    aligned, the 64-bit write needs to be split into two 32-bit writes
    to avoid the alignment exception.

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

    Saksham Jain