1. 31 Aug, 2014 6 commits
  2. 30 Aug, 2014 23 commits
  3. 29 Aug, 2014 11 commits
    • Chin Liang See's avatar
      socfpga: Fix SOCFPGA build error for Altera dev kit · 3ab019e1
      Chin Liang See authored
      To fix the build error when build for Altera dev kit, not
      virtual target. At same time, set the build for Altera dev
      kit as default instead virtual target. With that, U-Boot
      is booting well and SPL still lack of few drivers.
      Signed-off-by: default avatarChin Liang See <clsee@altera.com>
      Cc: Pavel Machek <pavel@denx.de>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Tom Rini <trini@ti.com>
      Cc: Albert Aribaud <albert.u.boot@aribaud.net>
      3ab019e1
    • Pavel Machek's avatar
      socfpga: fix clock manager register definition · 51fb455f
      Pavel Machek authored
      Structure defining clock manager hardware was wrong, leading to
      wrong registers being accessed and hang in MMC init.
      
      This fixes structure to match hardware.
      Signed-off-by: default avatarPavel Machek <pavel@denx.de>
      51fb455f
    • Christian Riesch's avatar
      arm: include config.h in arch/arm/lib/vectors.S · db993fc8
      Christian Riesch authored
      config.h is required for CONFIG_SYS_DV_NOR_BOOT_CFG.
      Signed-off-by: default avatarChristian Riesch <christian.riesch@omicron.at>
      Reported-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Albert Aribaud <albert.u.boot@aribaud.net>
      Cc: Masahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
      db993fc8
    • Jeroen Hofstee's avatar
      ARM:asm:io.h use static inline · 8863aa5c
      Jeroen Hofstee authored
      When compiling u-boot with W=1 the extern inline void for
      read* is likely causing the most noise. gcc / clang will
      warn there is never a actual declaration for these functions.
      Instead of declaring these extern make them static inline so
      it is actually declared.
      
      cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
      Signed-off-by: default avatarJeroen Hofstee <jeroen@myspectrum.nl>
      8863aa5c
    • Tom Rini's avatar
      6defdc0b
    • Tom Rini's avatar
      Merge git://git.denx.de/u-boot-usb · 8f005b39
      Tom Rini authored
      8f005b39
    • Tom Rini's avatar
    • Tom Rini's avatar
      5ddc3293
    • Tom Rini's avatar
      5a1095a8
    • Tom Rini's avatar
      6af857c5
    • Stephen Warren's avatar
      usb: hub: don't check CONNECTION in hub_port_reset() · 74c0d756
      Stephen Warren authored
      One specific USB 3.0 device behaves strangely when reset by
      usb_new_device()'s call to hub_port_reset(). For some reason, the device
      appears to briefly drop off the bus when this second bus reset is
      executed, yet if we retry this loop, it'll eventually come back after
      another two resets.
      
      If USB bus reset is executed over and over within usb_new_device()'s call
      to hub_port_reset(), I see the following sequence of results, which
      repeats as long as you want:
      
      1) STAT_C_CONNECTION = 1 STAT_CONNECTION = 0  USB_PORT_STAT_ENABLE 0
      2) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 0
      3) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 1
      
      The device in question is a SanDisk Ultra USB 3.0 16GB memory stick with
      USB VID/PID 0x0781/0x5581.
      
      In order to allow this device to work with U-Boot, ignore the
      {C_,}CONNECTION bits in the status/change registers, and only use the
      ENABLE bit to determine if the reset was successful.
      
      To be honest, extensive investigation has failed to determine why this
      problem occurs. I'd love to know! I don't know if it's caused by:
      * A HW bug in the device
      * A HW bug in the Tegra USB controller
      * A SW bug in the U-Boot Tegra USB driver
      * A SW bug in the U-Boot USB core
      
      This issue only occurs when the device's USB3 pins are attached to the
      host; if only the USB2 pins are connected the issue does not occur. The
      USB3 controller on Tegra is in reset, so is not actively communicating
      with the device at all - a USB3 analyzer confirms this. Slightly
      unplugging the device (so the USB3 pins don't contact) or using a USB2
      cable or hub as an intermediary avoids the problem. For some reason,
      the Linux kernel (either on the same Tegra board, or on an x86 host)
      has no issue with the device, and I observe no disconnections during
      reset.
      
      This change won't affect any USB device that already works, since such
      devices could not currently be triggering the error return this patch
      removes, or they wouldn't be working currently.
      
      However, this patch is quite reliable in practice, hence I hope it's
      acceptable to solve the problem.
      
      The only potential fallout I can see from this patch is:
      
      * A broken device that triggers C_CONNECTION/!CONNECTION now causes the
        loop in hub_port_reset() to run multiple times. If it never succeeds,
        this will cause "usb start" to take roughly 1s extra to execute.
      
      * If the user unplugs a device while hub_port_reset() is executing, and
        very quickly swaps in a new device, hub_port_reset() might succeed on
        the new device. This would mean that any information cached about the
        original device (from the descriptor read in usb_new_device(), which
        simply caches the max packet size) might be invalid, which would cause
        problems talking to the new device. However, without this change, the
        new device wouldn't work anyway, so this is probably not much of a
        loss.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      74c0d756