1. 14 Mar, 2016 2 commits
  2. 26 Feb, 2016 1 commit
  3. 24 Feb, 2016 3 commits
    • Michal Simek's avatar
      cmd: mem: Show 64bit addresses which are tested · dfe461d6
      Michal Simek authored
      Fix print message to show full 64bit addresses.
      Signed-off-by: default avatarMichal Simek <michal.simek@xilinx.com>
    • Karsten Merker's avatar
      booti: Help text rework. · 6f6051fa
      Karsten Merker authored
      Fix spelling errors in the "booti" help text and bring it more
      in line with the bootm/bootz help texts.
      Signed-off-by: default avatarKarsten Merker <merker@debian.org>
    • Lukasz Majewski's avatar
      dfu: usb: f_dfu: Set deferred call for dfu_flush() function · fc18f8d1
      Lukasz Majewski authored
      This patch fixes situation when one would like to write large file into
      medium with the file system (fat, ext4, etc).
      This change sets file size limitation to the DFU internal buffer size.
      Since u-boot is not supporting interrupts and seek on file systems, it
      becomes challenging to store large file appropriately.
      To reproduce this error - create large file (around 26 MiB) and sent it
      to the target board.
      Lets examine the flow of USB transactions:
      0. DFU uses EP0 with 64B MPS [Max Packet Size]
      1. Send file - OUT (PC->target) - dat_26MiB.img is sent with 4096 B transactions
      2. Get status - OUT (PC->target) - wait for DFU_STATE_dfuDNLOAD_IDLE (0x05) sent
      				   from target board - IN transaction
      3. The whole file content is sent to target - OUT (PC->target) with ZLP [Zero
      					      Length Packet]
      Now the interesting part starts:
      4. OUT (PC->target) Setup transaction (request to share DFU state)
      5. IN (target->PC) - reply the current DFU state
      	- In the UDC driver the req->completion (with dfu_flush) is called
      	  after successful IN transfer.
      	- The dfu_flush() (called from req->completion callback) saves the
      	  whole file at once (u-boot doesn't support seek on fs).
      	  Such operation takes considerable time. When the file
      	  is large - e.g. 26MiB - this time may be more than 5 seconds.
      6. OUT (PC->target) - ZLP, is send in the same time when dfu_flush()
       writes data to eMMC memory.
       The dfu-util application has hard coded timeout on USB transaction
       completion set to 5 seconds (it uses libusb calls).
      When the file to store is large (e.g. 26 MiB) the time needed to write it
      may excess the dfu-util timeout and following error message will be displayed:
      "unable to read DFU status" on the HOST PC console.
      This change is supposed to leverage DFU's part responsible for storing files
      on file systems. Other DFU operations - i.e. raw/partition write to NAND and
      eMMC should work as before.
      The only functional change is the error reporting. When dfu_flush() fails
      the u-boot prompt will exit with error information and dfu-util application
      exits afterwards as well.
      Test HW:
      - Odroid XU3 (Exynos5433) - test with large file
      - Trats (Exynos4210) - test for regression - eMMC, raw,
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Reported-by: default avatarAlex Gdalevich <agdalevich@axion-biosystems.com>
      Tested-by: default avatarStephen Warren <swarren@nvidia.com>
      Tested-by: default avatarHeiko Schocher <hs@denx.de>
  4. 22 Feb, 2016 1 commit
  5. 15 Feb, 2016 1 commit
  6. 09 Feb, 2016 1 commit
    • Stephen Warren's avatar
      itest: allow map_physmem to return 0 in limited cases · 986fe378
      Stephen Warren authored
      On some systems, RAM starts at address 0. If the user executes itest
      against address 0 on such a system, it will call map_physmem(0, ...)
      which will return 0 back; mapping only changes the address on sandbox.
      This causes itest to believe map_physmem() has failed, and hence fails
      the comparison.
      Fix itest so that it allows map_physmem() to return 0 /if/ the orignal
      address passed to it was also 0.
      This fixes "tegra-uboot-flasher flash" on Tegra20.
      This has the disadvantage that on sandbox, failed mapping attempts for
      address 0 are not detected. Instead, should the code only call
      map_physmem() on sandbox? Or, should map_physmem() return its error status
      some other way. Or, should the special case only be allowed on systems
      where the base of RAM is 0 somehow?
      Fixes: 7861204c
       ("itest: make memory access work under sandbox")
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
  7. 08 Feb, 2016 1 commit
  8. 06 Feb, 2016 2 commits
  9. 29 Jan, 2016 2 commits
    • Stephen Warren's avatar
      Implement "pci enum" command for CONFIG_DM_PCI · e578b92c
      Stephen Warren authored
      With CONFIG_DM_PCI enabled, PCI buses are not enumerated at boot, as they
      are without that config option enabled. No command exists to enumerate the
      PCI buses. Hence, unless some board-specific code causes PCI enumeration,
      PCI-based Ethernet devices are not detected, and network access is not
      This patch implements "pci enum" in the CONFIG_DM_PCI case, thus giving a
      mechanism whereby PCI can be enumerated.
      do_pci()'s handling of case 'e' is moved into a single location before the
      dev variable is assigned, in order to skip calculation of dev. The enum
      sub-command doesn't need the dev value, and skipping its calculation
      avoids an irrelevant error being printed.
      Using a command to initialize PCI like this has a disadvantage relative to
      enumerating PCI at boot. In particular, Ethernet devices are not probed
      during PCI enumeration, but only when used. This defers setting variables
      such as ethact, ethaddr, etc. until the first network-related command is
      executed. Hopefully this will not cause further issues. Perhaps in the
      long term, we need a "net start/enum" command too?
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarBin Meng <bmeng.cn@gmail.com>
    • Christophe Ricard's avatar
      tpm: Fix fault in case CONFIG_DM_TPM is set without any TPM · 0e37d4c2
      Christophe Ricard authored
      In case CONFIG_DM_TPM was set without any TPM chipset configured a fault
      was generated (NULL pointer access).
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
  10. 27 Jan, 2016 2 commits
  11. 25 Jan, 2016 3 commits