Commit graph

53 commits

Author SHA1 Message Date
Heinrich Schuchardt
e301e024e5 efi_loader: EFI_PRINT instead of debug for memory services
For debug messages inside EFI API functions we should use the EFI_PRINT
macro which gives us well aligned output like:

EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718)
  EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes
EFI: Exit: efi_allocate_pool_ext: 0

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-04-07 14:17:06 +02:00
Heinrich Schuchardt
2c3ec28935 efi_loader: sanity checks when freeing memory
Use a checksum to validate that efi_free_pool() is only called for memory
allocated by efi_allocated_pool().

Add a plausibility check to efi_free_pages() checking that the address
passed is page aligned.

Update related function comments to match Sphinx style.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-04-07 14:17:06 +02:00
Heinrich Schuchardt
306b16718e efi_loader: correct parameter size in efi_allocate_pool
efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of
the assigned memory. If we pass the address of a pointer here, an illegal
memory access occurs on 32bit systems.

Fixes: 282a06cbca ("efi_loader: Expose U-Boot addresses in memory map
for sandbox")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-03-20 18:16:53 +01:00
Heinrich Schuchardt
23f5f4abf7 efi_loader: fix memory allocation on sandbox
Commit 7b78d6438a ("efi_loader: Reserve unaccessible memory") introduced
a comparison between RAM top and RAM start that was not known at the time
when the patch of commit 49759743bf ("efi_loader: eliminate sandbox
addresses") was written.

The sandbox uses an address space that is only relevant in the sandbox
context. We have to map ram_top from the sandbox address space to the
physical address space before using it in the EFI subsystem.

Fixes: 49759743bf ("efi_loader: eliminate sandbox addresses")
Fixes: 7b78d6438a ("efi_loader: Reserve unaccessible memory")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2019-02-13 09:40:05 +01:00
Alexander Graf
7a82c3051c efi_loader: Align runtime section to 64kb
The UEFI spec mandates that runtime sections are 64kb aligned to enable
support for 64kb page size OSs.

This patch ensures that we extend the runtime section to 64kb to be spec
compliant.

Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02 21:59:37 +01:00
Heinrich Schuchardt
c3772ca1e3 efi_loader: macro efi_size_in_pages()
When allocating EFI memory pages the size in bytes has to be converted to
pages.

Provide a macro efi_size_in_pages() for this conversion.
Use it in the EFI subsystem and correct related comments.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02 21:59:37 +01:00
Heinrich Schuchardt
49759743bf efi_loader: eliminate sandbox addresses
Do not use the sandbox's virtual address space for the internal structures
of the memory map. This way we can eliminate a whole lot of unnecessary
conversions.

The only conversion remaining is the one when adding known memory.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02 21:59:37 +01:00
Alexander Graf
7b78d6438a efi_loader: Reserve unaccessible memory
On some systems, not all RAM may be usable within U-Boot. Maybe the
memory maps are incomplete, maybe it's used as workaround for broken
DMA. But whatever the reason may be, a platform can say that it does
not wish to have its RAM accessed above a certain address by defining
board_get_usable_ram_top().

In the efi_loader world, we ignored that hint, mostly because very few
boards actually have real restrictions around this.

So let's honor the board's wish to not access high addresses during
boot time. The best way to do so is by indicating the respective pages
as "allocated by firmware". That way, Operating Systems will still
use the pages after boot, but before boot no allocation will use them.

Reported-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Baruch Siach <baruch@tkos.co.il>
2018-12-02 21:59:37 +01:00
Heinrich Schuchardt
108bdff84a efi_loader: correct efi_add_known_memory()
If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the
number of memory pages may be incorrectly calculated.

We have to round up the start address and to round down the end address
to determine which complete pages are provided by the memory bank.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02 21:59:37 +01:00
Alexander Graf
c2e1ad70a7 efi_loader: Ensure memory allocations are page aligned
When the max_addr parameter of efi_find_free_memory() is within bounds
of an existing map and fits the reservation, we just return that address
as allocation value.

That breaks however if max_addr is not page aligned. So ensure that it
always comes to us page aligned, simplifying the allocation logic.

Without this, I've seen breakage where we were allocating pages at -1U
(32bit) which fits into a region that spans beyond 0x100000000. In that
case, we would return 0xffffffff as a valid memory allocation, although
we usually do guarantee they are all page aligned.

Fix this by aligning the max address argument always.

Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02 21:59:37 +01:00
Alexander Graf
7b05667ce2 efi_loader: Merge memory map entries
We currently do not combine memory entries that are adjacent and have
the same attributes. The problem with that is that our memory map can
easily grow multiple hundreds of entries in a simple UEFI Shell
environment.

So let's make sure we always combine all entries to make the memory
map as small as possible. That way every other piece of code that
loops through it should also gain some nice speed ups.

Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-23 21:55:30 +02:00
Stephen Warren
14deb5e628 Revert "Revert "efi_loader: efi_allocate_pages is too restrictive""
This reverts commit ccfc78b820.

Now that the underlying issue is fixed, we can revert the revert and hence
restore the original EFI code.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-23 21:55:29 +02:00
Masahiro Yamada
dee37fc99d Remove <inttypes.h> includes and PRI* usages in printf() entirely
In int-ll64.h, we always use the following typedefs:

  typedef unsigned int         u32;
  typedef unsigned long        uintptr_t;
  typedef unsigned long long   u64;

This does not need to match to the compiler's <inttypes.h>.
Do not include it.

The use of PRI* makes the code super-ugly.  You can simply use
"l" for printing uintptr_t, "ll" for u64, and no modifier for u32.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-09-10 20:48:17 -04:00
Eugeniu Rosca
9b89183b97 efi: Fix truncation of constant value
Starting with commit 867a6ac86d ("efi: Add start-up library code"),
sparse constantly complains about truncated constant value in efi.h:

include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0)

This can get quite noisy, preventing real issues to be noticed:

$ make defconfig
*** Default configuration is based on 'sandbox_defconfig'
$ make C=2 -j12 2>&1 | grep truncates | wc -l
441

After the patch is applied:
$ make C=2 -j12 2>&1 | grep truncates | wc -l
0
$ sparse --version
v0.5.2

Following the suggestion of Heinrich Schuchardt, instead of only
fixing the root-cause, I replaced the whole enum of _SHIFT values
by ULL defines. This matches both the UEFI 2.7 spec and the Linux
kernel implementation.

Some ELF size comparison before and after the patch (gcc 7.3.0):

efi-x86_payload64_defconfig:
text    data    bss     dec       hex   filename
407174  29432   278676  715282    aea12 u-boot.old
407152  29464   278676  715292    aea1c u-boot.new
-22     +32     0       +10

efi-x86_payload32_defconfig:
text    data    bss     dec       hex   filename
447075  30308   280076  757459    b8ed3 u-boot.old
447053  30340   280076  757469    b8edd u-boot.new
-22     +32     0       +10

Fixes: 867a6ac86d ("efi: Add start-up library code")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-08-21 00:03:01 +02:00
Heinrich Schuchardt
fa995d0d94 efi_loader: avoid NULL dereference in efi_get_memory_map()
We should only dereference parameter memory_map_size after checking that
it is valid.

Fixes: 8e835554b3 ("efi_loader: check parameters of GetMemoryMap")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-08-20 14:41:09 +02:00
Stephen Warren
ccfc78b820 Revert "efi_loader: efi_allocate_pages is too restrictive"
This reverts commit aa909462d0. This change
caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for
example when running test/py.

Reverting this change isn't optimal, but at least restores TX1 to a working
state. In the future, we should:

a) Fix whatever problem causes the crash with this patch applied. This
needs further discussion, so isn't something we can immediately do.

b) Undo the revert; re-apply the original patch to efi_allocate_pages.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-08-20 11:39:19 +02:00
Heinrich Schuchardt
1fcb7ea284 efi_loader: check map_key in ExitBootServices
The UEFI spec requires that the memory map key is checked in
ExitBootServices().

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25 14:59:44 +02:00
Heinrich Schuchardt
8e835554b3 efi_loader: check parameters of GetMemoryMap
Check the parameters of boottime service GetMemoryMap().
Return EFI_INVALID_PARAMETER where required by the UEFI spec.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25 14:59:44 +02:00
Heinrich Schuchardt
4d5e071ee0 efi_loader: check parameters in memory allocation
If no pointer is provided throw an error.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25 14:59:44 +02:00
Alexander Graf
282a06cbca efi_loader: Expose U-Boot addresses in memory map for sandbox
We currently expose host addresses in the EFI memory map. That can be
bad if we ever want to use sandbox to boot strap a real kernel, because
then the kernel would fetch its memory table from our host virtual address
map. But to make that use case work, we would need to have full control
over the address space the EFI application sees.

So let's expose only U-Boot addresses to the guest until we get to the
point of allocation. EFI's allocation functions are fun - they can take
U-Boot addresses as input values for hints and return host addresses as
allocation results through the same uint64_t * parameter. So we need to
be extra careful on what to pass in when.

With this patch I am successfully able to run the efi selftest suite as
well as grub.efi on aarch64.

Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25 14:57:44 +02:00
Simon Glass
69259b8367 efi: sandbox: Adjust memory usage for sandbox
With sandbox the U-Boot code is not mapped into the sandbox memory range
so does not need to be excluded when allocating EFI memory. Update the EFI
memory init code to take account of that.

Signed-off-by: Simon Glass <sjg@chromium.org>
[agraf: Remove map_sysmem() call and header reference]
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25 14:57:44 +02:00
Heinrich Schuchardt
aa909462d0 efi_loader: efi_allocate_pages is too restrictive
When running on the sandbox the stack is not necessarily at a higher memory
address than the highest free memory.

There is no reason why the checking of the highest memory address should be
more restrictive for EFI_ALLOCATE_ANY_PAGES than for
EFI_ALLOCATE_MAX_ADDRESS.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
[agraf: use -1ULL instead]
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25 14:57:43 +02:00
Heinrich Schuchardt
3282614081 efi_loader: efi_mem_carve_out should return s64
efi_mem_carve_out() is used to remove memory pages from a mapping.
As the number of pages to be removed is a 64bit type the return type
should be 64bit too.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-06-03 15:27:21 +02:00
Heinrich Schuchardt
e09159c867 efi_loader: avoid anonymous constants for AllocatePages
Do not use anonymous constants when calling efi_allocage_pages.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-06-03 15:27:21 +02:00
Heinrich Schuchardt
1f0532ca15 efi_loader: remove unnecessary include
asm/global_data.h is already included via common.h.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-06-03 15:27:20 +02:00
Tom Rini
f739fcd831 SPDX: Convert a few files that were missed before
As part of the main conversion a few files were missed.  These files had
additional whitespace after the '*' and before the SPDX tag and my
previous regex was too strict.  This time I did a grep for all SPDX tags
and then filtered out anything that matched the correct styles.

Fixes: 83d290c56f ("SPDX: Convert all of our single license tags to Linux Kernel style")
Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-10 20:38:35 -04:00
Simon Glass
bdecaebd5d efi: Correct header order in efi_memory
The headers are not in the correct order. Fix this. Also drop libfdt_env.h
since it is not needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Rebased
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-04-04 11:00:07 +02:00
Heinrich Schuchardt
7c92fd69b1 efi_loader: use constants in efi_allocate_pages()
Using the existing predefined constants is less error prone and
makes the code easier to read.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-04-04 11:00:07 +02:00
Masahiro Yamada
b08c8c4870 libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h>
Thomas reported U-Boot failed to build host tools if libfdt-devel
package is installed because tools include libfdt headers from
/usr/include/ instead of using internal ones.

This commit moves the header code:
  include/libfdt.h         -> include/linux/libfdt.h
  include/libfdt_env.h     -> include/linux/libfdt_env.h

and replaces include directives:
  #include <libfdt.h>      -> #include <linux/libfdt.h>
  #include <libfdt_env.h>  -> #include <linux/libfdt_env.h>

Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-05 10:16:28 -05:00
Heinrich Schuchardt
474a6f5aa1 efi_loader: add comments to memory functions
Add comments describing memory functions.

Fix the formatting of a function declaration.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-01-22 23:09:12 +01:00
Heinrich Schuchardt
f5a2a93892 efi_loader: consistently use efi_uintn_t in boot services
Consistenly use efi_uintn_t wherever the UEFI spec uses
UINTN in boot services interfaces.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-12-01 13:22:56 +01:00
Rob Clark
946160f334 efi_loader: make pool allocations cacheline aligned
This avoids printf() spam about file reads (such as loading an image)
into unaligned buffers (and the associated memcpy()).  And generally
seems like a good idea.

Signed-off-by: Rob Clark <robdclark@gmail.com>
[agraf: use __aligned]
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-20 10:48:09 +02:00
Rob Clark
a1b24823b6 efi_loader: fix bug in efi_get_memory_map
When booting shim -> fallback -> shim -> grub -> linux the memory map is
a bit larger than the size linux passes in on the first call.  But in
the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size
to linux so it would loop forever.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-07-26 22:09:49 +02:00
xypron.glpk@gmx.de
c6e3c3e68a efi_memory: return MapKey
efi_get_memory_map should set a defined value for map_key.

We later can introduce the test against this value in
efi_exit_boot_services as required by the UEFI standard.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-07-24 14:46:13 +02:00
xypron.glpk@gmx.de
0ecba5db85 efi_memory: do parameter checks first
The parameter checks should be done first.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-07-24 14:46:01 +02:00
xypron.glpk@gmx.de
71275a3e98 efi_memory: avoid NULL dereference in efi_free_pool
If efi_free_pool is called with argument NULL an illegal memory
access occurs.

So let's check the parameter on entry.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-07-19 14:14:41 +02:00
York Sun
426337455e efi: Add a hook to allow adding memory mapping
Instead of adding all memory banks, add a hook so individual SoC/board
can has its own implementation.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Alexander Graf <agraf@suse.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
2017-03-14 08:44:03 -07:00
Stefan Brüns
511d0b97ef efi_loader: Do not leak memory when unlinking a mapping
As soon as a mapping is unlinked from the list, there are no further
references to it, so it should be freed. If it not unlinked,
update the start address and length.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18 09:08:08 +02:00
Stefan Brüns
b6a9517275 efi_loader: Keep memory mapping sorted when splitting an entry
The code assumes sorted mappings in descending address order. When
splitting a mapping, insert the new part next to the current mapping.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18 09:08:07 +02:00
Stefan Brüns
b61d857b2f efi_loader: Readd freed pages to memory pool
Currently each allocation creates a new mapping. Readding the mapping
as free memory (EFI_CONVENTIONAL_MEMORY) potentially allows to hand out
an existing mapping, thus limiting the number of mapping descriptors in
the memory map.

Mitigates a problem with current (4.8rc7) linux kernels when doing an
efi_get_memory map, resulting in an infinite loop. Space for the memory
map is reserved with allocate_pool (implicitly creating a new mapping) and
filled. If there is insufficient slack space (8 entries) in the map, the
space is freed and a new round is started, with space for one more entry.
As each round increases requirement and allocation by exactly one, there
is never enough slack space. (At least 32 entries are allocated, so as
long as there are less than 24 entries, there is enough slack).
Earlier kernels reserved no slack, and did less allocations, so this
problem was not visible.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18 09:08:07 +02:00
Stefan Brüns
42417bc84d efi_loader: Track size of pool allocations to allow freeing
We need a functional free_pool implementation, as otherwise each
allocate_pool causes growth of the memory descriptor table.

Different to free_pages, free_pool does not provide the size for the
to be freed allocation, thus we have to track the size ourselves.

As the only EFI requirement for pool allocation is an alignment of
8 bytes, we can keep allocating a range using the page allocator,
reserve the first 8 bytes for our bookkeeping and hand out the
remainder to the caller. This saves us from having to use any
independent data structures for tracking.

To simplify the conversion between pool allocations and the corresponding
page allocation, we create an auxiliary struct efi_pool_allocation.

Given the allocation size free_pool size can handoff freeing the page
range, which was indirectly allocated by a call to allocate_pool,
to free_pages.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18 09:08:07 +02:00
Stefan Brüns
ead1274b7f efi_loader: Move efi_allocate_pool implementation to efi_memory.c
We currently handle efi_allocate_pool() in our boot time service
file. In the following patch, pool allocation will receive additional
internal semantics that we should preserve inside efi_memory.c instead.

As foundation for those changes, split the function into an externally
facing efi_allocate_pool_ext() for use by payloads and an internal helper
efi_allocate_pool() in efi_memory.c that handles the actual allocation.

While at it, change the magic 0xfff / 12 constants to the more obvious
EFI_PAGE_MASK/SHIFT defines.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18 09:08:07 +02:00
Stefan Brüns
bdf5c1b360 efi_loader: Fix memory map size check to avoid out-of-bounds access
The current efi_get_memory_map() function overwrites the map_size
property before reading its value. That way the sanity check whether our
memory map fits into the given array always succeeds, potentially
overwriting arbitrary payload memory.

This patch moves the property update write after its sanity check, so
that the check actually verifies the correct value.

So far this has not triggered any known bugs, but we're better off safe
than sorry.

If the buffer is to small, the returned memory_map_size indicates the
required size to the caller.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18 09:08:07 +02:00
Stefan Brüns
852efbf5bd efi_loader: Update description of internal efi_mem_carve_out
In 74c16acce3 the return values where
changed, but the description was kept.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18 09:08:06 +02:00
Mian Yousaf Kaukab
4c02c11de8 efi_loader: provide efi_mem_desc version
Provide version of struct efi_mem_desc in efi_get_memory_map().

EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines
memory descriptor version to 1. Linux kernel also expects descriptor
version to be 1 and prints following warning during boot if its not:

Unexpected EFI_MEMORY_DESCRIPTOR version 0

Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>
2016-09-07 08:49:07 -04:00
Andreas Färber
c933ed94bc efi_loader: Add debug output for efi_add_memory_map()
Tracing the arguments has been helpful for pinpointing overflows.

Cc: Alexander Graf <agraf@suse.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
2016-07-22 14:46:23 -04:00
Alexander Graf
74c16acce3 efi_loader: Don't allocate from memory holes
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
memory.

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: Jonathan Gray <jsg@jsg.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
2016-06-06 13:39:16 -04:00
Alexander Graf
edcef3ba1d efi_loader: Move to normal debug infrastructure
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: Alexander Graf <agraf@suse.de>
2016-06-06 13:39:16 -04:00
Alexander Graf
51735ae0ea efi_loader: Add bounce buffer support
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: Alexander Graf <agraf@suse.de>
2016-05-27 15:39:48 -04:00
Andreas Färber
dede284d1c efi_loader: Handle memory overflows
jetson-tk1 has 2 GB of RAM at 0x80000000, causing gd->ram_top to be zero.
Handle this by either avoiding ram_top or by using the same type as
ram_top to reverse the overflow effect.

Cc: Alexander Graf <agraf@suse.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Alexander Graf <agraf@suse.de>
2016-04-18 17:11:44 -04:00