1. 25 Apr, 2018 3 commits
  2. 23 Apr, 2018 3 commits
  3. 21 Apr, 2018 1 commit
    • Marek Vasut's avatar
      ARM: rmobile: Update E2 Silk · f7aa3cd4
      Marek Vasut authored
      
      
      The E2 Silk port was broken since some time. This patch updates
      the E2 Silk port to use modern frameworks, DM, DT probing, SPL
      for the preloading and puts it on par with the M2 Porter board.
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
      ---
      NOTE: The port is missing support for I2C1 for DA9063 reset, since the
            I2C driver needs to be converted to DM and DT probing. That's not
            an issue for this patch though, since the reset was broken on Silk
            since forever.
      f7aa3cd4
  4. 18 Apr, 2018 1 commit
  5. 17 Apr, 2018 7 commits
  6. 15 Apr, 2018 9 commits
    • Trent Piepho's avatar
      imx: Create distinct pre-processed mkimage config files · f9167573
      Trent Piepho authored and Stefano Babic's avatar Stefano Babic committed
      Each imx image is created by a separate sub-make and during this process
      the mkimage config file is run though cpp.
      
      The cpp output is to the same file no matter what imx image is being
      created.
      
      This means if two imx images are generated in parallel they will attempt
      to independently produce the same pre-processed mkimage config file at
      the same time.
      
      Avoid the problem by making the pre-processed config file name unique
      based on the imx image it will be used in.  This way each image will
      create a unique config file and they won't clobber each other when run
      in parallel.
      
      This should fixed the build bug referenced in b5b0e4e3
      
       ("imximage:
      Remove failure when no IVT offset is found").
      
      Cc: Breno Lima <breno.lima@nxp.com>
      Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: default avatarTrent Piepho <tpiepho@impinj.com>
      Tested-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      f9167573
    • Tom Rini's avatar
      mx31ads: Delete · 448fc44f
      Tom Rini authored and Stefano Babic's avatar Stefano Babic committed
      
      
      This platform has been marked as orphaned since September 2013, remove.
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
      448fc44f
    • Tom Rini's avatar
      imx31_phycore: Delete · bcca8aa9
      Tom Rini authored and Stefano Babic's avatar Stefano Babic committed
      
      
      This platform has been marked as orphaned since September 2013, remove.
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
      bcca8aa9
    • Bryan O'Donoghue's avatar
      imx: mx7: snvs: Add an SNVS init routine · 723f8359
      Bryan O'Donoghue authored and Stefano Babic's avatar Stefano Babic committed
      
      
      Working with HAB on the i.MX7 we've encountered a case where a board that
      successfully authenticates u-boot when booting Linux via OPTEE subsequently
      fails to properly bring up the RTC.
      
      The RTC registers live in the low-power block of the Secure Non-Volatile
      Storage (SNVS) block.
      
      The root cause of the error has been traced to the HAB handing off the
      SNVS-RTC in a state where HPCOMR::NPSWA_EN = 0 in other words where the
      Non-Privileged Software Access Enable bit is zero. In ordinary
      circumstances this is OK since we typically do not run in TZ mode, however
      when we boot via HAB and enablng TrustZone, it is required to set
      HPCOMR::NPSWA_EN = 1 in order for the upstream Linux driver to have
      sufficient permissions to manipulate the SNVS-LP block.
      
      On our reference board it is the difference between Linux doing this:
      
      root@imx7s-warp-mbl:~# dmesg | grep rtc
      snvs_rtc_enable read 0x00000000 from SNVS_LPLR @ 0x00000034
      snvs_rtc_enable read 0x00000021 from SNVS_LPCR @ 0x00000038
      snvs_rtc_enable read 0x00000000 from SNVS_HPLR @ 0x00000000
      snvs_rtc_enable read 0x80002100 from SNVS_HPCOMR @ 0x00000004
      snvs_rtc 30370000.snvs:snvs-rtc-lp: rtc core: registered
               30370000.snvs:snvs-rtc-lp as rtc0
      snvs_rtc 30370000.snvs:snvs-rtc-lp: setting system clock to2018-04-01 00:51:04 UTC (1522543864)
      
      and doing this:
      
      root@imx7s-warp-mbl:~# dmesg | grep rtc
      snvs_rtc_enable read 0x00000000 from SNVS_LPLR @ 0x00000034
      snvs_rtc_enable read 0x00000020 from SNVS_LPCR @ 0x00000038
      snvs_rtc_enable read 0x00000001 from SNVS_HPLR @ 0x00000000
      snvs_rtc_enable read 0x00002020 from SNVS_HPCOMR @ 0x00000004
      snvs_rtc 30370000.snvs:snvs-rtc-lp: failed to enable rtc -110
      snvs_rtc: probe of 30370000.snvs:snvs-rtc-lp failed with error -110
      hctosys: unable to open rtc device (rtc0)
      
      Note bit 1 of LPCR is not set in the second case and is set in the first
      case and that bit 31 of HPCOMR is set in the second case but not in the
      first.
      
      Setting NPSWA_EN in HPCOMR allows us to boot through enabling TrustZone
      and continue onto the kernel. The kernel then has the necessary permissions
      to set LPCR::SRTC_ENV (RTC enable in the LP command register) whereas in
      contrast - in the failing case the non-privileged kernel cannot do so.
      
      This patch adds a simple init_snvs() call which sets the permission-bit
      called from soc.c for the i.MX7. It may be possible, safe and desirable to
      perform this on other i.MX processors but for now this is only tested on
      i.MX7 as working.
      Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      723f8359
    • Lukasz Majewski's avatar
      imx: board: Add support for the K+P's kp_imx6q_tpc board · dd4671cb
      Lukasz Majewski authored and Stefano Babic's avatar Stefano Babic committed
      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
    • Bryan O'Donoghue's avatar
      imx: hab: Provide hab_auth_img_or_fail command · 49e62426
      Bryan O'Donoghue authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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
      imx: mx7: Add comment to describe OTP TESTER registers · 1ab1ffde
      Bryan O'Donoghue authored and Stefano Babic's avatar Stefano Babic committed
      
      
      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 and Stefano Babic's avatar Stefano Babic committed
      
      
      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 and Stefano Babic's avatar Stefano Babic committed
      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: Marek Vasut's 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: Stefano Babic's avatarStefano Babic <sbabic@denx.de>
      14eeb683
  7. 13 Apr, 2018 5 commits
  8. 11 Apr, 2018 5 commits
    • Marek Vasut's avatar
      ARM: rmobile: Fix the memory map on Gen3 · 7beccc52
      Marek Vasut authored and Marek Vasut's avatar Marek Vasut committed
      
      
      Fix up the memory map on Gen3 to match datasheet properly.
      This simplifies the memory map setup as well, since we do
      no longer need this massive complexity.
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
      7beccc52
    • Marek Vasut's avatar
      ARM: rmobile: Add JTAG recovery support for M2 Porter · 82239aa7
      Marek Vasut authored
      
      
      Add JTAG recovery support into the M2 Porter TPL. This allows the
      TPL to be loaded over JTAG, initialize the system, wait for the
      JTAG debugger to load U-Boot image into RAM and then resume and
      start U-Boot from RAM.
      
      The procedure is as follows:
      1) Load u-boot-tpl.bin to 0xe6300000
      2) Write magic number 0x1337c0de to 0xe6300020
         TPL checks for this particular magic and starts JTAG recovery
         if this number is present. This is not present by default.
      3) Start U-Boot TPL from 0xe6300000
      4) Wait for a message from TPL on UART indicating JTAG boot:
         "JTAG boot detected!"
      5) Halt the system in JTAG debugger
      6) Load U-Boot image (u-boot.img) to 0x4fffffc0
      7) Write magic number 0xb33fc0de to 0xe6300024
         TPL checks for this particular magic to verify that the U-Boot
         image was loaded into DRAM by the JTAG debugger.
      8) Resume the system in JTAG debugger
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
      82239aa7
    • Marek Vasut's avatar
      ARM: rmobile: Add TPL support on R8A7791 M2 Porter · 9a5483e9
      Marek Vasut authored
      
      
      Add and enable TPL on M2 Porter. The TPL must fit into 16 kiB due
      to the Gen2 BootROM restriction. The TPL is running from MERAM and
      is capable of performing the initial initialization of PFC, Clock,
      GPIO, LBSC, DBSC and QSPI NOR. DBSC is responsible for bringing up
      the DDR DRAM access. The TPL is capable of loading the next stage,
      U-Boot, from either SPI NOR or UART as a fallback. If either does
      provide a valid U-Boot uImage, the system stops, which allows the
      operator to load U-Boot ie. via JTAG and start it manually.
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
      9a5483e9
    • Marek Vasut's avatar
      ARM: rmobile: Do not init caches in TPL before DRAM · c6706073
      Marek Vasut authored
      
      
      Skip the cache initialization, which can be done later on in U-Boot
      proper, since this interferes with early DRAM initialization in TPL.
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
      c6706073
    • Marek Vasut's avatar
      ARM: Fix Makefile during SPL and TPL build · a821a77a
      Marek Vasut authored and Tom Rini's avatar Tom Rini committed
      
      
      The tiny variants of memset and memcpy implementations can be
      built for TPL as well, check whether a TPL build is in progress
      and avoid including the default variants.
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Tom Rini <trini@konsulko.com>
      a821a77a
  9. 10 Apr, 2018 1 commit
  10. 09 Apr, 2018 5 commits