1. 20 Oct, 2015 2 commits
  2. 19 Oct, 2015 2 commits
    • Fabio Estevam's avatar
      dfu: dfu_sf: Take the start address into account · 2727f3bf
      Fabio Estevam authored
      The dfu_alt_info_spl variable allows passing a starting point
      for the binary to be flashed in the SPI NOR.
      
      For example, if we have 'dfu_alt_info_spl=spl raw 0x400', this means
      that we want to flash the binary starting at address 0x400.
      
      In order to do so we need to erase the entire sector and write to
      the the subsequent SPI NOR sectors taking such start address
      into account for the address calculations.
      
      Tested by succesfully writing SPL binary into 0x400 offset and
      the u-boot.img at offset 64 kiB of a SPL NOR.
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Acked-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      [trini: Use lldiv for the math]
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      2727f3bf
    • Fabio Estevam's avatar
      dfu: dfu_sf: Use the erase sector size for erase operations · f4c92582
      Fabio Estevam authored
      SPI NOR flashes need to erase the entire sector size and we cannot pass
      any arbitrary length for the erase operation.
      
      To illustrate the problem:
      
      Copying data from PC to DFU device
      Download    [=========================] 100%       478208 bytes
      Download done.
      state(7) = dfuMANIFEST, status(0) = No error condition is present
      state(10) = dfuERROR, status(14) = Something went wrong, but the
      device does not know what it was
      Done!
      
      In this case, the binary has 478208 bytes and the M25P32 SPI NOR
      has an erase sector of 64kB.
      
      478208  = 7 entire sectors of 64kiB + 19456 bytes.
      
      Erasing the first seven 64 kB sectors works fine, but when trying
      to erase the remainding 19456 causes problem and the board hangs.
      
      Fix the issue by always erasing with the erase sector size.
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Acked-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      f4c92582
  3. 15 Oct, 2015 2 commits
  4. 13 Oct, 2015 4 commits
  5. 12 Oct, 2015 2 commits
    • Fabio Estevam's avatar
      ls102xa: Fix reset hang · f861f51c
      Fabio Estevam authored
      Since commit 623d96e8("imx: wdog: correct wcr register settings")
      issuing a 'reset' command causes the system to hang.
      
      Unlike i.MX and Vybrid, the watchdog controller on LS102x is big-endian.
      
      This means that the watchdog on LS1021 has been working by accident as
      it does not use the big-endian accessors in drivers/watchdog/imx_watchdog.c.
      Commit 623d96e8("imx: wdog: correct wcr register settings") only
      revelead the endianness problem on LS102x.
      
      In order to fix the reset hang, introduce a reset_cpu() implementation that
      is specific for ls102x, which accesses the watchdog WCR register in big-endian
      format. All that is required to reset LS102x is to clear the SRS bit.
      
      This approach is a temporary workaround to avoid a regression for LS102x
      in the 2015.10 release. The proper fix is to make the watchdog driver
      endian-aware, so that it can work for i.MX, Vybrid and LS102x.
      Reported-by: default avatarSinan Akman <sinan@writeme.com>
      Tested-by: default avatarSinan Akman <sinan@writeme.com>
      Reviewed-by: default avatarWolfgang Denk <wd@denx.de>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      f861f51c
    • Fabio Estevam's avatar
      imx_watchdog: Add a header file for watchdog registers · f532727d
      Fabio Estevam authored
      Create fsl_wdog.h to store the watchdog registers and bit fields.
      
      This can be useful when accesses to the watchdog block are made from other
      parts, such as arch/arm/ cpu code.
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      f532727d
  6. 11 Oct, 2015 6 commits
  7. 08 Oct, 2015 1 commit
  8. 05 Oct, 2015 2 commits
    • Simon Glass's avatar
      sandbox: Correct operaion of 'reset' command · 7bb91dd1
      Simon Glass authored
      Currently 'reset' only works with the test device tree. When run without a
      device tree, or with the normal device tree, the following error is
      displayed:
      
         Reset not supported on this platform
      
      Fix the driver and the standard device tree to avoid this.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Reported-by: default avatarStephen Warren <swarren@nvidia.com>
      Tested-by: default avatarStephen Warren <swarren@wwwdotorg.org>
      7bb91dd1
    • Simon Glass's avatar
      dm: core: Don't use pinctrl for the root device · 84d26e29
      Simon Glass authored
      Currently when driver model starts up it finds the root uclass and the
      pinctrl uclass. This is because even the root node handles pinctrl
      processing.
      
      But this is not useful. The root node is not a real hardware device so
      cannot require any particular pinmux settings. Also it means that the
      memory leak tests fails, since they end up freeing more memory than
      they allocate: the marker it set after the root device and pinctrl
      uclass are allocated, and later once the pinctrl uclass is freed the memory
      used by driver model is less than when the marker was set.
      
      If a platform needs 'core' pin mulitplex settings it can do this with
      a driver that is probed on start-up. It would be an abuse of the root node
      to use this for pinctrl.
      
      To avoid this problem, only process pinctrl settings for non-root nodes.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      84d26e29
  9. 03 Oct, 2015 2 commits
  10. 02 Oct, 2015 5 commits
  11. 30 Sep, 2015 1 commit
  12. 29 Sep, 2015 3 commits
  13. 28 Sep, 2015 1 commit
  14. 24 Sep, 2015 7 commits