1. 22 Jul, 2016 1 commit
  2. 06 Jun, 2016 2 commits
    • Alexander Graf's avatar
      efi_loader: Don't allocate from memory holes · 74c16acc
      Alexander Graf authored
      When a payload calls our memory allocator with the exact address hint, we
      happily allocate memory from completely unpopulated regions. Payloads however
      expect this to only succeed if they would be allocating from free conventional
      This patch makes the logic behind those checks a bit more obvious and ensures
      that we always allocate from known good free conventional memory regions if we
      want to allocate ram.
      Reported-by: default avatarJonathan Gray <jsg@jsg.id.au>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
    • Alexander Graf's avatar
      efi_loader: Move to normal debug infrastructure · edcef3ba
      Alexander Graf authored
      We introduced special "DEBUG_EFI" defines when the efi loader
      support was new. After giving it a bit of thought, turns out
      we really didn't have to - the normal #define DEBUG infrastructure
      works well enough for efi loader as well.
      So this patch switches to the common debug() and #define DEBUG
      way of printing debug information.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
  3. 27 May, 2016 1 commit
    • Alexander Graf's avatar
      efi_loader: Add bounce buffer support · 51735ae0
      Alexander Graf authored
      Some hardware that is supported by U-Boot can not handle DMA above 32bits.
      For these systems, we need to come up with a way to expose the disk interface
      in a safe way.
      This patch implements EFI specific bounce buffers. For non-EFI cases, this
      apparently was no issue so far, since we can just define our environment
      variables conveniently.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
  4. 18 Apr, 2016 2 commits
  5. 01 Apr, 2016 1 commit
  6. 16 Mar, 2016 1 commit
    • Alexander Graf's avatar
      efi_loader: Implement memory allocation and map · 5d00995c
      Alexander Graf authored
      The EFI loader needs to maintain views of memory - general system memory
      windows as well as used locations inside those and potential runtime service
      MMIO windows.
      To manage all of these, add a few helpers that maintain an internal
      representation of the map the similar to how the EFI API later on reports
      it to the application.
      For allocations, the scheme is very simple. We basically allow allocations
      to replace chunks of previously done maps, so that a new LOADER_DATA
      allocation for example can remove a piece of the RAM map. When no specific
      address is given, we just take the highest possible address in the lowest
      RAM map that fits the allocation size.
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      Tested-by: default avatarSimon Glass <sjg@chromium.org>