1. 24 Sep, 2014 2 commits
  2. 16 Sep, 2014 8 commits
  3. 15 Sep, 2014 1 commit
  4. 10 Sep, 2014 3 commits
    • Simon Glass's avatar
      dm: Make driver model available before board_init() · 9fb02491
      Simon Glass authored
      For some boards board_init() will change GPIOs, so we need to have driver
      model available before then. Adjust the board init to arrange this, but
      enable it for driver model only, just to be safe.
      
      This does create additional #ifdef logic, but it is safer than trying to
      make a pervasive change which may cause some boards to break.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      9fb02491
    • Simon Glass's avatar
      Set up stdio earlier when using driver model · 294b91a5
      Simon Glass authored
      Since driver model registers itself with the stdio subsystem, and we
      want to avoid delayed registration and other complexity associated with
      the current serial console, move the stdio subsystem init earlier when
      driver model is used for serial.
      
      This simplifies the implementation. Should there be any problems with
      this approach they can be dealt with as boards are converted over to
      use driver model for serial.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      294b91a5
    • Simon Glass's avatar
      dm: Move pre-reloc init earlier to cope with board_early_init_f() · 3ea0953d
      Simon Glass authored
      In order to support GPIO access in board_early_init_f() we must set up
      driver model before this function is called. In any case, earlier is
      better since driver model is (or will become) a key function for most
      init.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      3ea0953d
  5. 09 Sep, 2014 1 commit
  6. 02 Sep, 2014 1 commit
    • Lukasz Majewski's avatar
      dfu: Provide means to find difference between dfu-util -e and -R · 1cc03c5c
      Lukasz Majewski authored
      This commit provides distinction between DFU device detach and reset.
      The -R behavior is preserved with proper handling of the dfu-util's -e
      switch, which detach the DFU device.
      
      By running dfu-util -e; one can force device to finish the execution of
      dfu command on target and execute some other scripted commands.
      
      Moreover, some naming has been changed - the dfu_reset() method now is known
      as dfu_detach(). New name better reflects the purpose of the code.
      
      It was also necessary to increase the number of usb_gadget_handle_interrupts()
      calls since we also must wait for detection of the USB reset event.
      
      Example usage:
      1. -e (detach) switch
       dfu-util -a0 -D file1.bin;dfu-util -a3 -D uImage;dfu-util -e
      
       access to u-boot prompt.
      
      2. -R (reset) switch
       dfu-util -a0 -D file1.bin;dfu-util -R -a3 -D uImage
      
       target board reset
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Reviewed-by: default avatarStephen Warren <swarren@nvidia.com>
      Tested-by: default avatarStephen Warren <swarren@nvidia.com>
      1cc03c5c
  7. 01 Sep, 2014 2 commits
    • Simon Glass's avatar
      dm: gpio: Allow gpio command to adjust GPIOs that are busy · 9165e842
      Simon Glass authored
      The gpio command mostly relies on gpio_request() and gpio_free() being
      nops, in that you can request a GPIO twice. With driver model this is
      now implemented correctly, so it fails.
      
      Change the command to deal with a failure to claim the GPIO.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      9165e842
    • Simon Glass's avatar
      dm: gpio: Enhance gpio command to show only active GPIOs · 89e64054
      Simon Glass authored
      The GPIO list is very long in many cases and most of them are not used.
      By default, show only the GPIOs that are in use, and provide a flag to show
      all of them. This makes the 'gpio status' command much more pleasant.
      
      In order to do this, driver model now exposes a method for obtaining the
      'function' of a GPIO, which describes whether it is an input or output, for
      example. Implementation of this method is optional.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      89e64054
  8. 30 Aug, 2014 1 commit
    • Tom Rini's avatar
      cmd_bootm.c: Add 'booti' for ARM64 Linux kernel Images · d2b2ffe3
      Tom Rini authored
      The default format for arm64 Linux kernels is the "Image" format,
      described in Documentation/arm64/booting.txt.  This, along with an
      optional gzip compression on top is all that is generated by default.
      The Image format has a magic number within the header for verification,
      a text_offset where the Image must be run from, an image_size that
      includes the BSS and reserved fields.
      
      This does not support automatic detection of a gzip compressed image.
      Signed-off-by: default avatarTom Rini <trini@ti.com>
      d2b2ffe3
  9. 29 Aug, 2014 2 commits
    • 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
    • Marek Vasut's avatar
      usb: Handle -ENODEV from usb_lowlevel_init() · 97b9eb9e
      Marek Vasut authored
      As we support both Host and Device mode operation, an OTG controller
      can return -ENODEV on a port which it found to be in Device mode during
      Host mode scan for devices. In case -ENODEV is returned, print that the
      port is not available and continue instead of screaming a bloody error
      message.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      97b9eb9e
  10. 28 Aug, 2014 1 commit
    • Simon Glass's avatar
      Fix test failure caused by bad handling of ramdisk · fe20a81a
      Simon Glass authored
      Commit e3a5bbce broke the FIT image tests by not loading a ramdisk even if
      a load address is provided in the FIT. The rationale was that a load address
      of 0 should be considered to mean 'do not load'.
      
      Add a new load operation which supports this feature, so that the ramdisk
      will be loaded if a non-zero load address is provided.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      fe20a81a
  11. 25 Aug, 2014 2 commits
  12. 24 Aug, 2014 1 commit
  13. 21 Aug, 2014 4 commits
  14. 20 Aug, 2014 1 commit
  15. 14 Aug, 2014 1 commit
  16. 11 Aug, 2014 2 commits
  17. 10 Aug, 2014 2 commits
  18. 09 Aug, 2014 5 commits