1. 22 Mar, 2016 4 commits
  2. 18 Mar, 2016 1 commit
  3. 17 Mar, 2016 1 commit
  4. 16 Mar, 2016 4 commits
    • Tom Rini's avatar
      cmd: scsi: Group the command portion together, guard with !CONFIG_SPL_BUILD · ba524269
      Tom Rini authored
      When we switch to including all linker lists in SPL it is important
      to not include commands as that may lead to link errors due to other
      things we have already discarded.  In this case, the SCSI code needs a lot
      of attention so for now just guard the command portions.
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      ba524269
    • Alexander Graf's avatar
      efi_loader: Pass proper device path in on boot · 0f4060eb
      Alexander Graf authored
      EFI payloads can query for the device they were booted from. Because
      we have a disconnect between loading binaries and running binaries,
      we passed in a dummy device path so far.
      
      Unfortunately that breaks grub2's logic to find its configuration
      file from the same device it was booted from.
      
      This patch adds logic to have the "load" command call into our efi
      code to set the device path to the one we last loaded a binary from.
      
      With this grub2 properly detects where we got booted from and can
      find its configuration file, even when searching by-partition.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      0f4060eb
    • Alexander Graf's avatar
      efi_loader: Call fdt preparation functions · dea2174d
      Alexander Graf authored
      We have a nice framework around image fils to prepare a device tree
      for OS execution. That one patches in missing device tree nodes and
      fixes up the memory range bits.
      
      We need to call that one from the EFI boot path too to get all those
      nice fixups. This patch adds the call.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      dea2174d
    • Alexander Graf's avatar
      efi_loader: Add "bootefi" command · b9939336
      Alexander Graf authored
      In order to execute an EFI application, we need to bridge the gap between
      U-Boot's notion of executing images and EFI's notion of doing the same.
      
      The best path forward IMHO here is to stick completely to the way U-Boot
      deals with payloads. You manually load them using whatever method to RAM
      and then have a simple boot command to execute them. So in our case, you
      would do
      
        # load mmc 0:1 $loadaddr grub.efi
        # bootefi $loadaddr
      
      which then gets you into a grub shell. Fdt information known to U-boot
      via the fdt addr command is also passed to the EFI payload.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      Tested-by: default avatarSimon Glass <sjg@chromium.org>
      [trini: Guard help text with CONFIG_SYS_LONGHELP]
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      b9939336
  5. 14 Mar, 2016 13 commits
  6. 26 Feb, 2016 1 commit
  7. 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>
      dfe461d6
    • 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>
      6f6051fa
    • 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
      				   (target->PC)
      
      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>
      fc18f8d1
  8. 22 Feb, 2016 1 commit
  9. 15 Feb, 2016 1 commit
  10. 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>
      986fe378
  11. 08 Feb, 2016 1 commit
  12. 06 Feb, 2016 2 commits
  13. 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
      available.
      
      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>
      e578b92c
    • 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>
      0e37d4c2
  14. 27 Jan, 2016 2 commits
  15. 25 Jan, 2016 3 commits