14 Dec, 2021

1 commit


12 Mar, 2021

1 commit


10 Mar, 2021

5 commits

  • system will hang at line 1834 which will hold console_waiter
    1833 /* Owner will clear console_waiter on hand off */
    1834 while (READ_ONCE(console_waiter))
    1835 cpu_relax();
    1836 spin_release(&console_owner_dep_map, _THIS_IP_);

    It means console_lock_spinning_disable_and_check is not called in time.
    So console_unlock may not called in time.
    remove earlycon as workaround.

    Change-Id: I5742c0ade6e289d1a96a67b27b4e55f2e1732187
    Signed-off-by: zhang sanshan
    (cherry picked from commit 74938a70b5fece2d1f3f60e74596f393a40e5713)

    zhang sanshan
     
  • The BKEK will bind to the soc chip and we don't need to
    store the encapsulated keyslot after using BKEK as the
    rpmb key, which reduces the risk of losing the rpmb key.

    This commit adds two commands to support derive the rpmb
    key from BKEK and erase the rpmb storage (for debug purpose,
    need support from trusty):
    $ fastboot oem set-rpmb-hardware-key
    $ fastboot oem erase-rpmb

    Legacy keyslot way is still supported and boards programed
    with keyslot can still work in compatible way. Command
    to set provisioned rpmb key is changed to:
    $ fastboot stage
    $ fastboot oem set-rpmb-staged-key

    Test: Key set and boot on imx8mn/imx8qxp.

    Change-Id: Ifc88010fe8802d3550e42dff0bbd5a5e5ad922a3
    Signed-off-by: Ji Luo
    (cherry picked from commit 0fd1b5e41645ac3f5c05ad82258df1645c59fb5a)

    Ji Luo
     
  • Add support for generating BKEK, this is necessary
    to support derive the rpmb key from bkek.

    Test: BKEK generation.

    Change-Id: I4c192a3e1d080ca49655537705d31678d1ca689a
    Signed-off-by: Ji Luo
    (cherry picked from commit 048934cebaa2035bf54dbd9bd32de3f782cb07df)

    Ji Luo
     
  • The latest declare of usb_gadget_handle_interrupts has a parameter
    to pass the USB controller index. We can use this index for DWC3
    interrupt handler to avoid hard code for USB controller 0.
    This will save a change when porting to second USB controller.

    Signed-off-by: Ye Li
    Reviewed-by: Peng Fan
    (cherry picked from commit 6a678c46b01c620755dc4eb4334caf475faf0ee8)

    Ye Li
     
  • qspihdr is a new subsystem in u-boot to check/updat q(f)spi boot config
    headers. It's already integrated with uuu and can be used to burn
    q(f)spi boot images for i.MX6/7/8 families.

    Basic usage:
    check [addr]: check if exists valid q(f)spi boot config header at
    spcified memory addr, or check the nor chip without addr
    dump [addr] : dump q(f)spi boot config header content from spcified
    memory addr, or from nor chip without addr
    init addr len safe: burn boot image from memory addr with size of len to
    q(f)spi, with safe boot config header
    update safe : only update header in q(f)spi to a safe boot config

    Signed-off-by: Han Xu
    (cherry picked from commit dc0ba70f5ba04425e9562c1dd4f6dcb7db322f4b)

    Han Xu
     

05 Mar, 2021

2 commits

  • * origin/ls_v2020.04:
    arm64: gic-v3-its: Clear the Pending table before enabling LPIs

    BJ DevOps Team
     
  • The GICv3 RM requires "The first 1KB of memory for the LPI Pending tables
    must contain only zeros on initial allocation, and this must be visible
    to the Redistributors, or else the effect is UNPREDICTABLE".

    And as the following statement, we here clear the whole Pending tables
    instead of the first 1KB.
    "An LPI Pending table that contains only zeros, including in the first 1KB,
    indicates that there are no pending LPIs.
    The first 1KB of the LPI Pending table is IMPLEMENTATION DEFINED. However,
    if the first 1KB of the LPI Pending table and the rest of the table contain
    only zeros, this must indicate that there are no pending LPIs."

    And there isn't any pending LPI under U-Boot, so it's unnecessary to
    loading the contents of the Pending table during the enablement, then set
    the GICR_PENDBASER.PTZ flag.

    Signed-off-by: Hou Zhiqiang
    Tested-by: Vladimir Oltean

    Hou Zhiqiang
     

01 Mar, 2021

1 commit


27 Feb, 2021

1 commit


23 Feb, 2021

1 commit


21 Feb, 2021

1 commit

  • Users reported LPDDR4 MR12 value is set to 0 during PHY training,
    not the value from FSP timing structure, which cause compliance test failed.
    The root cause is the CATrainOpt[0] is set to 1 in 2D FSP timing
    but not set in 1D. According to PHY training application node,
    to enable the feature both 1D and 2D need set this field to 1,
    otherwise the training result will be incorrect.
    The PHY training doc also recommends to set CATrainOpt[0] to 0 to use
    MR12 value from message block (FSP structure). So update the LPDDR4
    scripts of all mscale to clear CATrainOpt[0].

    Signed-off-by: Ye Li
    Reviewed-by: Jacky Bai
    (cherry picked from commit 2c98fb859258478e0f8bb8df980a96edff19d359)

    Ye Li
     

05 Feb, 2021

13 commits


28 Jan, 2021

3 commits


27 Jan, 2021

3 commits

  • * origin/ls_v2020.04:
    net: memac_phy: add a timeout to MDIO operations
    armv8: lx2: SVR_SOC_VER: Mask CAN_FD and security bit

    BJ DevOps Team
     
  • We have encountered circumstances when a board design does not include
    pull-up resistors on the external MDIO buses which are not used. This
    leads to the MDIO data line not being pulled-up, thus the MDIO controller
    will always see the line as busy.

    Without a timeout in the MDIO bus driver, the execution is stuck in an
    infinite loop when any access is initiated on that external bus.

    Add a timeout in the driver so that we are protected in this
    circumstance. This is similar to what is being done in the Linux
    xgmac_mdio driver.

    Signed-off-by: Ioana Ciornei

    Ioana Ciornei
     
  • Multiple LX2(LX2160A/LX2162A SoC) personality variants
    exists based on CAN-FD and security bit in SVR.

    Currenly SVR_SOC_VER mask only security bit.
    Update SVR_SOC_VER to mask CAN_FD and security bit
    for LX2 products.

    Signed-off-by: Wasim Khan

    Wasim Khan
     

17 Jan, 2021

3 commits


14 Jan, 2021

3 commits

  • * origin/imx_v2020.04:
    LF-3161-2 mx6ul: bee: Remove XN bit for bee enabled region
    LF-3161-1 arm: imx: Fix speculative instruction prefetch issue

    BJ DevOps Team
     
  • We will test a program on BEE enabled region, so remove XN bit
    to allow execution when current MMU domain is changed to client.

    Signed-off-by: Ye Li
    Reviewed-by: Peng Fan
    (cherry picked from commit e4bd1734bcba2012d4d7dea7598635256f155c96)

    Ye Li
     
  • Default ARM32 MMU setting in u-boot sets XN bit to entire 4GB space no
    matter which DCACHE option is used, and set domain permission to manager.
    This causes MMU ignores the access check and XN bit, so speculative
    instruction can fetch from entire space.

    This patch sets the DDR, ROM, OCRAM without XN bit, and set domain to client
    to enable the XN and access check. So speculative instruction fetch can only
    happens on these 3 regions to avoid prefetch from peripherals and invalid
    regions.

    Signed-off-by: Ye Li
    Reviewed-by: Peng Fan
    (cherry picked from commit 25d70768c460bad91aa65f367203af41122399cd)

    Ye Li
     

13 Jan, 2021

2 commits