Skip to content
Snippets Groups Projects
  1. Apr 15, 2018
    • Lukasz Majewski's avatar
      imx: board: Add support for the K+P's kp_imx6q_tpc board · dd4671cb
      Lukasz Majewski authored
      This commit provides support for Kieback & Peter GmbH IMX6Q based
      TPC board.
      
      U-boot console output:
      
      U-Boot SPL 2018.05-rc1-00005-g631e2d01fd (Apr 04 2018 - 21:16:24 +0200)
      Trying to boot from MMC1
      
      U-Boot 2018.05-rc1-00005-g631e2d01fd (Apr 04 2018 - 21:16:24 +0200)
      
      CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
      CPU:   Extended Commercial temperature grade (-20C to 105C) at 37C
      Reset cause: POR
      Board: K+P KP_IMX6Q_TPC i.MX6Q
             Watchdog enabled
      I2C:   ready
      DRAM:  2 GiB
      MMC:   FSL_SDHC: 0, FSL_SDHC: 1
      Loading Environment from MMC... OK
      In:    serial
      Out:   serial
      Err:   serial
      Net:   FEC [PRIME]
      Autoboot in 3 seconds
      dd4671cb
    • Ian Ray's avatar
      board: ge: bx50v3: enable backlight on demand · 6c0e6b45
      Ian Ray authored
      
      Enable display backlight only if a message needs to be displayed.
      The kernel re-initializes the backlight, which results in some
      unwanted artifacts.
      
      Signed-off-by: default avatarIan Ray <ian.ray@ge.com>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.co.uk>
      6c0e6b45
    • Ken Lin's avatar
      arm: imx: Add Winbond SPI-NOR support for Advantech DMS-BA16 board · 7a0ce1f7
      Ken Lin authored
      
      Windbond's been in the AVL list and need to enable the support
      
      Signed-off-by: default avatarKen Lin <yungching0725@gmail.com>
      7a0ce1f7
    • Bryan O'Donoghue's avatar
      imx: hab: Provide hab_auth_img_or_fail command · 49e62426
      Bryan O'Donoghue authored
      
      This patch adds hab_auth_img_or_fail() a command line function that
      encapsulates a common usage of authenticate and failover, namely if
      authenticate image fails, then drop to BootROM USB recovery mode.
      
      For secure-boot systems, this type of locked down behavior is important to
      ensure no unsigned images can be run.
      
      It's possible to script this logic but, when done over and over again the
      environment starts get very complex and repetitive, reducing that script
      repetition down to a command line function makes sense.
      
      Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      Cc: Utkarsh Gupta <utkarsh.gupta@nxp.com>
      Cc: Breno Lima <breno.lima@nxp.com>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      Tested-by: default avatarBreno Lima <breno.lima@nxp.com>
      49e62426
    • Bryan O'Donoghue's avatar
      imximage: Encase majority of header in __ASSEMBLY__ declaration · f4d8fccd
      Bryan O'Donoghue authored
      
      Subsequent patches will want to include imageimage.h but in doing so
      include it on an assembly compile path causing a range of compile errors.
      Fix the errors pre-emptively by encasing the majority of the declarations
      in imximage.h inside an ifdef __ASSEMBLY__ block.
      
      Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      Cc: Utkarsh Gupta <utkarsh.gupta@nxp.com>
      Cc: Breno Lima <breno.lima@nxp.com>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      Tested-by: default avatarBreno Lima <breno.lima@nxp.com>
      f4d8fccd
    • Bryan O'Donoghue's avatar
      warp7: Set u-boot serial# based on OTP value · 852cc548
      Bryan O'Donoghue authored
      
      u-boot has a standard "serial#" environment variable that is suitable
      for storing the iSerial number we will supply via the USB device
      descriptor. serial# is automatically picked up by the disk subsystem in
      u-boot - thus providing a handy unique identifier in /dev/disk/by-id as
      detailed below.
      
      Storing the hardware serial identifier in serial# means we can change the
      serial# if we want before USB enumeration - thus making iSerial automatic
      via OTP but overridable if necessary.
      
      This patch reads the defined OTP fuse and sets environment variable
      "serial#" to the value read.
      
      With this patch in place the USB mass storage device will appear in
      /dev/disk/by-id with a unique name based on the OTP value. For example
      
      /dev/disk/by-id/usb-Linux_UMS_disk_0_WaRP7-0xf42400d3000001d4-0:0
      
      Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Rui Miguel Silva <rui.silva@linaro.org>
      Cc: Ryan Harkin <ryan.harkin@linaro.org>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      852cc548
    • Bryan O'Donoghue's avatar
      imx: mx7: Add comment to describe OTP TESTER registers · 1ab1ffde
      Bryan O'Donoghue authored
      
      The tester registers provide a unique chip-level identifier which
      get_board_serial() returns in a "struct tag_serialnr".
      
      This patch documents the properties of the registers; in summary.
      
      31:0 OCOTP_TESTER0 (most significant)
      - FSL-wide unique, encoded LOT ID STD II/SJC CHALLENGE/ Unique ID
      
      OCOTP_TESTER1 (least significant)
      31:24
      - The X-coordinate of the die location on the wafer/SJC CHALLENGE/ Unique
        ID
      23:16
      - The Y-coordinate of the die location on the wafer/SJC CHALLENGE/ Unique
        ID
      15:11
      - The wafer number of the wafer on which the device was fabricated/SJC
        CHALLENGE/ Unique ID
      10:0
      - FSL-wide unique, encoded LOT ID STD II/SJC CHALLENGE/ Unique ID
      
      The 64 bits of data generate a unique serial number per-chip.
      
      Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Peng Fan <peng.fan@nxp.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      1ab1ffde
    • Bryan O'Donoghue's avatar
      imx: mx7: Fix CONFIG_SERIAL_TAG compilation · ca831822
      Bryan O'Donoghue authored
      
      Currently when we define CONFIG_SERIAL_TAG we will barf with a failure to
      define "struct tag_serialnr".
      
      This structure is defined in <asm/setup.h>, this patch includes
      <asm/setup.h> to fix.
      
      Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Peng Fan <peng.fan@nxp.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      ca831822
    • Marek Vasut's avatar
      ARM: mx6: ddr: Add write leveling correction code · 14eeb683
      Marek Vasut authored
      When the DDR calibration is enabled, a situation may happen that it
      will fail on a few select boards out of a whole production lot. In
      particular, after the first write leveling stage, the MPWLDECTRLx
      registers will contain a value 0x1nn , for nn usually being 0x7f or
      slightly lower.
      
      What this means is that the HW write leveling detected that the DQS
      rising edge on one or more bundles arrives slightly _after_ CLK and
      therefore when the DDR DRAM samples CLK on the DQS rising edge, the
      CLK signal is already high (cfr. AN4467 rev2 Figure 7 on page 18).
      
      The HW write leveling then ends up adding almost an entire cycle (thus
      the 0x17f) to the DQS delay, which indeed aligns it, but also triggers
      subsequent calibration failure in DQS gating due to this massive offset.
      
      There are two observations here:
      - If the MPWLDECTRLx value is corrected from 0x17f to 0x0 , then the
        DQS gating passes, the entire calibration passes as well and the
        DRAM is perfectly stable even under massive load.
      - When using the NXP DRAM calibrator for iMX6/7, the value 0x17f or so
        in MPWLDECTRx register is not there, but it is replaced by 0x0 as one
        would expect.
      
      Someone from NXP finally explains why, quoting [1]:
      
          "
          Having said all that, the DDR Stress Test does something that we
          do not advertise to the users. The Stress Test iself looks at the
          values of the MPWLDECTRL0/1 fields before reporting results, and
          if it sees any filed with a value greater than 200/256 delay
          (reported as half-cycle = 0x1 and ABS_OFFSET > 0x48), the DDR
          Stress test will reset the Write Leveling delay for this lane
          to 0x000 and not report it in the log.
      
          The reason that the DDR Stress test does this is because a delay
          of more than 78% a clock cycle means that the DQS edge is arriving
          within the JEDEC tolerence of 25% of the clock edge. In most cases,
          DQS is arriving < 5% tCK of the SDCLK edge in the early case, and
          it does not make sense to delay the DQS strobe almost a full clock
          cycle and add extra latency to each Write burst just to make the
          two edges align exactly. In this case, we are guilty of making a
          decision for the customer without telling them we are doing it so
          that we don't have to provide the above explanation to every customer.
          They don't need to know it.
          "
      
      This patch adds the correction described above, that is if the MPWLDECTRx
      value is over 0x148, the value is corrected back to 0x0.
      
      [1] https://community.nxp.com/thread/456246
      
      
      
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Reviewed-by: default avatarEric Nelson <eric@nelint.com>
      Reviewed-by: default avatarStefano Babic <sbabic@denx.de>
      14eeb683
    • Rasmus Villemoes's avatar
      tools/imximage: use 0x prefix in HAB Blocks line · 8519c9c9
      Rasmus Villemoes authored
      
      The u-boot-ivt.img.log file contains 0x prefixes in the HAB Blocks line,
      while the SPL.log does not. For consistency, and to make it easier to
      extract and put into a .csf file for use with NXP's code signing tool,
      add 0x prefixes here.
      
      Signed-off-by: default avatarRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Tested-by: default avatarBreno Lima <breno.lima@nxp.com>
      8519c9c9
    • Rasmus Villemoes's avatar
      Makefile: always preserve output for images that can contain HAB Blocks · 06587617
      Rasmus Villemoes authored
      
      The current makefile logic disables creation of the
      SPL.log/u-boot-ivt.img.log etc. files when V=1 is given on the command
      line, the rationale presumably being that the user wants and gets the
      information on the console.
      
      However, from general principles, I don't think a higher V= level
      should affect which build artifacts get generated (and certainly
      shouldn't produce fewer). Concretely, it's also a problem that when
      doing a V=1 build in a terminal, the relevant HAB blocks lines easily
      drown in all the other V=1 output.
      
      Moreover, build systems such as Yocto by default pass V=1, so in that
      case the information gets hidden away in the do_compile log file, making
      it nigh impossible to create a recipe for creating signed U-boot images
      - I don't want to disable V=1, because having verbose output in the log
      file is valuable when things go wrong, but OTOH trying to go digging in
      the do_compile log file (and getting exactly the right lines) is not
      pleasant to even think about.
      
      So change the logic so that for V=0, the mkimage output is redirected
      to MKIMAGEOUTPUT (which is also the current behaviour), while for any
      other value of V, we _additionally_ write the information to make's
      stdout, whatever that might be.
      
      Signed-off-by: default avatarRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Tested-by: default avatarBreno Lima <breno.lima@nxp.com>
      06587617
  2. Mar 29, 2018
  3. Mar 11, 2018
  4. Mar 09, 2018
Loading