1. 17 9月, 2014 1 次提交
    • P
      kgdb: Remove first_entry for kgdb · f9f040b2
      Peng Fan 提交于
      There are two ways to run into handle_exception, run command 'kgdb' and
      encounter a breakpoint which triggers exception handling.
      
      The origin source code only saves regs when first run command 'kgdb'.
      Take the following for example, When run 'kgdb', regs is saved to entry_regs.
      When run 'bootz', regs is not saved. However, if we set a breakpoint, then
      continue. When breakpoint is reached, run `quit`, and Now return to the
      instruction which follows kgdb, but not bootz.This may cause errors. So,
      save regs for each handle_exception call to return to the correct place.
      Example:
      Target      |    Host
      =>kgdb      |    (gdb)b bootz
                  |    (gdb)c
      =>bootz     |
                  |    (gdb)Here stop because of breakpoint
                  |    (gdb)q
      Signed-off-by: NPeng Fan <van.freenix@gmail.com>
      f9f040b2
  2. 16 9月, 2014 1 次提交
  3. 11 9月, 2014 3 次提交
    • S
      dm: Make driver model available before board_init() · 9fb02491
      Simon Glass 提交于
      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: NSimon Glass <sjg@chromium.org>
      9fb02491
    • S
      Set up stdio earlier when using driver model · 294b91a5
      Simon Glass 提交于
      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: NSimon Glass <sjg@chromium.org>
      294b91a5
    • S
      dm: Move pre-reloc init earlier to cope with board_early_init_f() · 3ea0953d
      Simon Glass 提交于
      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: NSimon Glass <sjg@chromium.org>
      3ea0953d
  4. 09 9月, 2014 1 次提交
  5. 02 9月, 2014 1 次提交
    • L
      dfu: Provide means to find difference between dfu-util -e and -R · 1cc03c5c
      Lukasz Majewski 提交于
      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: NLukasz Majewski <l.majewski@samsung.com>
      Reviewed-by: NStephen Warren <swarren@nvidia.com>
      Tested-by: NStephen Warren <swarren@nvidia.com>
      1cc03c5c
  6. 01 9月, 2014 2 次提交
    • S
      dm: gpio: Allow gpio command to adjust GPIOs that are busy · 9165e842
      Simon Glass 提交于
      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: NSimon Glass <sjg@chromium.org>
      9165e842
    • S
      dm: gpio: Enhance gpio command to show only active GPIOs · 89e64054
      Simon Glass 提交于
      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: NSimon Glass <sjg@chromium.org>
      89e64054
  7. 30 8月, 2014 1 次提交
    • T
      cmd_bootm.c: Add 'booti' for ARM64 Linux kernel Images · d2b2ffe3
      Tom Rini 提交于
      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: NTom Rini <trini@ti.com>
      d2b2ffe3
  8. 29 8月, 2014 3 次提交
    • S
      usb: hub: don't check CONNECTION in hub_port_reset() · 74c0d756
      Stephen Warren 提交于
      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: NStephen Warren <swarren@nvidia.com>
      74c0d756
    • M
      usb: Handle -ENODEV from usb_lowlevel_init() · 97b9eb9e
      Marek Vasut 提交于
      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: NMarek Vasut <marex@denx.de>
      97b9eb9e
    • S
      Fix test failure caused by bad handling of ramdisk · fe20a81a
      Simon Glass 提交于
      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: NSimon Glass <sjg@chromium.org>
      fe20a81a
  9. 26 8月, 2014 1 次提交
    • H
      mtd, ubi, ubifs: resync with Linux-3.14 · ff94bc40
      Heiko Schocher 提交于
      resync ubi subsystem with linux:
      
      commit 455c6fdbd219161bd09b1165f11699d6d73de11c
      Author: Linus Torvalds <torvalds@linux-foundation.org>
      Date:   Sun Mar 30 20:40:15 2014 -0700
      
          Linux 3.14
      
      A nice side effect of this, is we introduce UBI Fastmap support
      to U-Boot.
      Signed-off-by: NHeiko Schocher <hs@denx.de>
      Signed-off-by: NTom Rini <trini@ti.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Sergey Lapin <slapin@ossfans.org>
      Cc: Scott Wood <scottwood@freescale.com>
      Cc: Joerg Krause <jkrause@posteo.de>
      ff94bc40
  10. 25 8月, 2014 1 次提交
  11. 24 8月, 2014 1 次提交
  12. 22 8月, 2014 4 次提交
  13. 20 8月, 2014 1 次提交
  14. 14 8月, 2014 1 次提交
  15. 12 8月, 2014 1 次提交
  16. 11 8月, 2014 1 次提交
  17. 10 8月, 2014 2 次提交
  18. 09 8月, 2014 11 次提交
  19. 07 8月, 2014 1 次提交
  20. 02 8月, 2014 1 次提交
  21. 28 7月, 2014 1 次提交