1. 28 Aug, 2015 5 commits
  2. 26 Aug, 2015 1 commit
  3. 18 Aug, 2015 2 commits
  4. 17 Aug, 2015 3 commits
  5. 14 Aug, 2015 4 commits
  6. 13 Aug, 2015 8 commits
  7. 06 Aug, 2015 2 commits
  8. 05 Aug, 2015 6 commits
    • Marek Vasut's avatar
      usb: Fix device detection code · dcc7dbc7
      Marek Vasut authored
      The code in question polls an USB port status via USB_REQ_GET_STATUS
      to determine whether there is a device on the port or not. The way to
      figure that out is to check two bits. Those are wPortChange[0] and
      wPortStatus[0].
      
      The wPortChange[0] indicates whether some kind of a connection status
      change happened on a port (a device was plugged or unplugged). The
      wPortStatus[0] bit indicates the status of the connection (plugged or
      unplugged).
      
      The current code tests whether wPortChange[0] == wPortStatus[0] and
      if that's the case, considers the loop polling for the presence of a
      USB device on port finished.
      
      This works for most USB sticks, since they come up really quickly and
      trigger the USB port change detection before the first iteration of the
      detection loop happens. Thus, both wPortChange[0] and wPortStatus[0]
      are set to 1 and thus equal. The loop is existed in it's first iteration
      and the stick is detected correctly.
      
      The problem is with some obscure USB sticks, which take some time before
      they pop up on the bus after the port was enabled. In this case, both
      the wPortChange[0] and wPortStatus[0] are 0. They are equal again, so
      the loop again exits in the first iteration, but this is incorrect, as
      such USB stick didn't have the opportunity to get detected on the bus.
      
      Rework the code such, that it checks for wPortChange[0] first to test
      if any connection change happened at all. If no change occured, keep
      polling. If a change did occur, test the wPortStatus[0] to see there is
      some device present on the port and only if this is the case, break out
      of the polling loop.
      
      This patch also trims down the duration of the polling loop from 10s
      per port to 1s per port. This is still annoyingly long, but there is
      no better option in case of U-Boot unfortunatelly. This change will
      most likely increase the duration of 'usb start' on some platforms,
      but this is needed to fix a bug.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Hans de Goede <hdegoede@redhat.com>
      dcc7dbc7
    • Simon Glass's avatar
      efi: Add a command to display the memory map · f1a0bafb
      Simon Glass authored
      The EFI memory map is passed from the stub to U-Boot in a table. Add a
      command to display it in a vaguely readable fashion.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarBin Meng <bmeng.cn@gmail.com>
      Tested on QEMU
      Tested-by: default avatarBin Meng <bmeng.cn@gmail.com>
      f1a0bafb
    • Simon Glass's avatar
      Add a way to skip relocation · f05ad9ba
      Simon Glass authored
      When running U-Boot as an EFI application we cannot relocate since we do not
      have relocation information. U-Boot has already been relocated to a suitable
      address.
      
      Add a global_data flag to control skipping relocation.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarBin Meng <bmeng.cn@gmail.com>
      f05ad9ba
    • Ben Stoltz's avatar
      efi: Avoid using non-existent text base · 9b217498
      Ben Stoltz authored
      When U-Boot runs as an EFI application is does not have a definition of
      CONFIG_SYS_TEXT_BASE. U-Boot is a relocatable application and the relocation
      is done by EFI. U-Boot can be loaded at any address.
      
      This is similar to how sandbox works. Adjust the early board init to deal
      with this.
      Signed-off-by: default avatarBen Stoltz <stoltz@google.com>
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarBin Meng <bmeng.cn@gmail.com>
      9b217498
    • Peng Fan's avatar
      common: command add '\n' for debug msg · 58b6ad68
      Peng Fan authored
      Add '\n' for debug msg.
      Signed-off-by: default avatarPeng Fan <Peng.Fan@freescale.com>
      Cc: Tom Rini <trini@konsulko.com>
      Cc: Masahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Simon Glass <sjg@chromium.org>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      58b6ad68
    • Bin Meng's avatar
      common: Print nothing in the __weak checkboard() · 31dd0a9a
      Bin Meng authored
      Do not print confusing "Board: Unknown" during boot.
      Signed-off-by: default avatarBin Meng <bmeng.cn@gmail.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      31dd0a9a
  9. 28 Jul, 2015 1 commit
  10. 27 Jul, 2015 2 commits
    • Stephen Warren's avatar
      pxe: add AArch64 image support · 8b5c738b
      Stephen Warren authored
      The sysboot and pxe commands currently support either U-Boot formats or
      raw zImages. Add support for the AArch64 Linux port's native image format
      too.
      
      As with zImage support, there is no auto-detection of the native image
      format. Rather, if the image is auto-detected as a U-Boot format, U-Boot
      will try to interpret it as such. Otherwise, U-Boot will fall back to a
      raw/native image format, if one is enabled.
      
      My belief is that CONFIG_CMD_BOOTZ won't ever be enabled for any AArch64
      port, hence there's never a need to differentiate between CONFIG_CMD_
      _BOOTI and _BOOTZ at run-time; compile-time will do. Even if this isn't
      true, we want to prefer _BOOTI over _BOOTZ when defined, since _BOOTI is
      definitely the native format for AArch64.
      
      Change-Id: I83c5cc7566032afd72516de46f4e5eb7a780284a
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      8b5c738b
    • Haikun.Wang@freescale.com's avatar
      generic_board: Call "checkboard" even though the root node has a "model" property · dac326b8
      Haikun.Wang@freescale.com authored
      In case of enable CONFIG_OF_CONTROL and has a "model" property in the root node,
      the board special "checkboard" will not be called.
      Usually we show some useful version information in the function.
      This patch enable call "checkboard" in any case.
      It is not conflicting with showing "model" at the same time.
      
      For example on LS2085AQDS:
      Showing "model" only:
      Model: Freescale Layerscape 2085a QDS Board
      
      Showing "checkboard" only:
      Board: LS2085E-QDS, Board Arch: V1, Board version: B, boot from vBank: 4
      
      Showing both:
      Model: Freescale Layerscape 2085a QDS Board
      Board: LS2085E-QDS, Board Arch: V1, Board version: B, boot from vBank: 4
      Signed-off-by: default avatarHaikun Wang <haikun.wang@freescale.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      dac326b8
  11. 24 Jul, 2015 1 commit
    • Stefan Roese's avatar
      spl: spl_mmc: Add option to boot from a MMC partition with offset · 4bfcc54c
      Stefan Roese authored
      This patch introduces the option to boot from a MMC card parition with
      an offset. This can be done by using both defines together:
      
      define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION 1
      define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR    ((160 << 10) / 512)
      
      The example above loads the main U-Boot at offset 160KiB from the MMC
      partition 1.
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      Cc: Luka Perkov <luka.perkov@sartura.hr>
      Cc: Dirk Eibach <eibach@gdsys.de>
      Cc: Tom Rini <trini@konsulko.com>
      4bfcc54c
  12. 22 Jul, 2015 2 commits
  13. 21 Jul, 2015 3 commits